Re: suggested patch to allow user to access their own file...

["Darrick J. Wong" <darrick.wong@oracle.com>]

> Cc: bfoster@redhat.com, xfs-oss <xfs@e29208.dscx.akamaiedge.net>

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