Re: [PATCH v6 3/3] openat2: add OA2_CRED_INHERIT flag

[stsp]

04.05.2024 23:38, Donald Buczek пишет:
> On 4/27/24 13:24, Stas Sergeev wrote:
> > This flag performs the open operation with the fs credentials
> > (fsuid, fsgid, group_info) that were in effect when dir_fd was opened.
> > dir_fd must be opened with O_CRED_ALLOW, or EPERM is returned.
> >
> > Selftests are added to check for these properties as well as for
> > the invalid flag combinations.
> >
> > This allows the process to pre-open some directories and then
> > change eUID (and all other UIDs/GIDs) to a less-privileged user,
> > retaining the ability to open/create files within these directories.
> >
> > Design goal:
> > The idea is to provide a very light-weight sandboxing, where the
> > process, without the use of any heavy-weight techniques like chroot
> > within namespaces, can restrict the access to the set of pre-opened
> > directories.
> > This patch is just a first step to such sandboxing. If things go
> > well, in the future the same extension can be added to more syscalls.
> > These should include at least unlinkat(), renameat2() and the
> > not-yet-upstreamed setxattrat().
> >
> > Security considerations:
> > - Only the bare minimal set of credentials is overridden:
> >    fsuid, fsgid and group_info. The rest, for example capabilities,
> >    are not overridden to avoid unneeded security risks.
> > - To avoid sandboxing escape, this patch makes sure the restricted
> >    lookup modes are used. Namely, RESOLVE_BENEATH or RESOLVE_IN_ROOT.
> > - Magic /proc symlinks are discarded, as suggested by
> >    Andy Lutomirski <luto@xxxxxxxxxx>> - O_CRED_ALLOW fds cannot be 
> > passed via unix socket and are always
> >    closed on exec() to prevent "unsuspecting userspace" from not being
> >    able to fully drop privs.
>
> What about hard links?
Well, you set umask to 0 in your example.
If you didn't do that, the dir wouldn't have
0777 perms, and the hard link would not
be created.
But yes, that demonstrates the unsafe
usage scenario, i.e. unsafe directory perms
immediately lead to a security hole.
Maybe O_CRED_ALLOW should check for
safe perms, or maybe it shouldn't... So far
there are no signs of this patch to ever be
accepted, so I am not sure if more complexity
needs to be added to it.