Vào Th 5, 24 thg 10, 2024 vào lúc 19:59 Janne Johansson <icepic...@gmail.com> đã viết: > > > On Thu, Oct 24, 2024 at 11:36:17AM +0200, Janne Johansson wrote: > > > > >Description: > > > > On a same filestem, /tmp or /var in www pages perhaps or > > > > perhaps even / if they get that deep, > > > > the risk exists that a user can archive a file away even though > > > > they don't have permissions > > > > to that file. It allows at least a "backup" of non-user owned > > > > files, to be put away for > > > > later examination. Whether this is intended or not to be this > > > > way I don't know. It's all > > > > ghoti to me. > > > > > > Yes, this is intended. A directory entry points to an inode, and the > > > inode points to the file contents, which will only be shown to you if > > > you pass the validation (ie, ownership checks) of the inode. The fact > > > that you can write an extra dir-entry in a writable directory is not a > > > huge security risk, since you are not able to change ownership of > > > "your" hard link, so if you could not read it before, then you can't > > > read it after the "original" is removed either, or just "later". > > > > Thanks for the lengthy explanation. My query then is, why can someone > > archive away files anyhow. The original user may not even know that > > his/her files are saved by someone else. > > > > Just because they aren't able to be read by the *linker* doesn't mean > > he/she will never have permissions to read them. Right? > > I can't tell, whatever method you use to gain access to your newly > hardlinked content could well be used to change the permissions on the > original unlinked file also, "at some later point", so we are still at > the same place as before. >
The author said they have done a backup of the password file :) That's true. The file now have two links point to it. You have to remove all the links to the file now. Allowing any user to create hard links to files not owned and readable by them create security risks, not just privacy risks. It is called time of check to time of use. There is an easy to understand example on Wikipedia. https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use#Examples So, the attacker may replace the file a root process will be working on with a hardlink to a file not owned by them. This affect Linux most because most Linux distributions suggest using a single root partition. But Linux distributions are now having tmpfs for /tmp by default, so creating hardlink to /etc/spwd.db is not possible... So the attacher now create symlinks instead. I think there should be hardening to stop users from creating hardlinks and symlinks to the file they don't own...
