> Cc: bfoster@xxxxxxxxxx, xfs-oss <xfs@xxxxxxxxxxxxxxxxxxxxxxxxxx> akamaiedge.net ?? Er, did my mailer do that, or did yours? [re-adding linux-xfs to cc] On Mon, Jan 04, 2021 at 12:24:14PM -0800, L A Walsh wrote: > > > On 2021/01/04 10:44, Darrick J. Wong wrote: > > This would open a huge security hole because users can use it to bypass > > directory access checks. > --- > Can't say I entirely disagree. Though given the prevalence of that > behavior being "normal" on NT due to the "Bypass Traverse Checking" "right" > being on by default in a standard Windows setup, That might be true on Windows, but CAP_DAC_* isn't given out by default on Linux. > I would question it being a 'huge' security hole, though it would be > an unwanted change in behavior. I think people would consider it a hole of /some/ kind, since this patch wouldn't even require the process to hold CAP_DAC_* privilege. > If a user has a shell open to a directory that is made > inaccessible in the way you describe, though, simply staying connected > would seem to allow opening FD's that would be otherwise inaccessible. > > Further, can't a user pass an open file descriptor through > some type of IPC call for the other side to use? I may be misremembering > something similar, so I'd have to dig unless someone else remembers. Yes, they can do both of those things, since the Unix DAC only checks access at open time. > Though, in the following case: > > > > have a file /home/djwong/bin/pwnme, r/w by EBM (evil Bitcom minor). > > then someone issues chmod 0000 on a dir above it... > > Now I cannot access pwnme anymore, because I've been cut off from ~/bin. > ---- > Oh...but if they hard linked it to someone else's open dir, > they still could. It seems if you want to secure the object, you really > need to alter the perms on object, not on what might be 1 of > several paths to it. It might be bind-mounted elsewhere as well. I /did/ say that the BOFH omitted -r... ;) > Additionally you aren't dealing with removing more permissive > ACL's... That said, you're still right in that it opens a new > potential security hole that anyone from MS would be used to/expecting > (that's not to be taken as a justification to do it, just as context > for expectations and level of the security hole. > > Conversely, while users may have ownership rights in their > home dir, they may not have write permissions above that -- possibly > not even read permissions if that 'nt-right' is ever supported. > > I'm guessing it's not easy to check if they might have path > permissions to get there, though the intervening files could be accessible > through a group ACL, that the user is a member of. Might > be good to keep such files only executable by owner. > > So I'd beg off on supporting that change now, without some > other way of checking accessibility (which could be np-hard given > the number of ways its possible to get around a simple directory blockade). > > Given the wide use of linux as a file server, I'm wondering > how one might support the extra 'right's from windows in some context. > > Certainly, if the above scenario was used within a Linux-subsystem running > on windows, the resulting access modes could > be complicated. > > This is way beyond this question (here, don't patch unless you > check other CAPs), but wouldn't it make sense to have the ability > to apply an LSM-model (or set of rules) only to some specific domain > (in this case path traversal/access over diverse file systems that > have different rules and capabilities)? Yeah. As far as I can tell, CAP_DAC_OVERRIDE actually /does/ give you the security permissions that you want. The sysadmin can then decide who gets to have that permission, so you /could/ propose doing that. > If it isn't possible already, I'm sure it soon will be > the case that users will be on systems that have different file > systems mounted. If an xfs file system is mounted under an NT > file system and the user is running Windows, wouldn't NT-rights > (like ignoring traversal issues) apply by default, as NT would > be in charge of enforcing security as it walked through a locally > mounted XFS file system? When would NT be walking through a locally mounted XFS filesystem? --D
