From: Stephen Smalley <stephen.smalley.work@gmail.com>
To: Chirantan Ekbote <chirantan@chromium.org>
Cc: Jeffrey Vander Stoep <jeffv@google.com>,
Nick Kralevich <nnk@google.com>, Paul Moore <paul@paul-moore.com>,
Eric Paris <eparis@parisplace.org>,
Dylan Reid <dgreid@chromium.org>,
Suleiman Souhlal <suleiman@chromium.org>,
SElinux list <selinux@vger.kernel.org>
Subject: Re: [PATCH] selinux: Allow file owner to set "security.sehash"
Date: Fri, 12 Jun 2020 08:40:38 -0400 [thread overview]
Message-ID: <CAEjxPJ5UtA7ixPd0Je6tMgBuykqo_tJDp-gRDY89M--9dQb_3A@mail.gmail.com> (raw)
In-Reply-To: <CAJFHJrp560C=KB-LNdMAbJB=r9byUJ0Pgd5u9=o8vHrsB3Ht2Q@mail.gmail.com>
On Fri, Jun 12, 2020 at 12:00 AM Chirantan Ekbote
<chirantan@chromium.org> wrote:
>
> On Fri, Jun 5, 2020 at 9:23 PM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> >
> > On Fri, Jun 5, 2020 at 2:21 AM Chirantan Ekbote <chirantan@chromium.org> wrote:
> > >
> >
> > > The background for this patch is that I have a fuse server that runs
> > > in a user namespace. It runs as root in that namespace and keeps all
> > > the file system caps so that it can set selinux xattrs. However, it
> > > cannot set the sehash xattr as that needs CAP_SYS_ADMIN in the parent
> > > namespace. Looking at the code I thought that might have just been an
> > > oversight but if it's intentional then do you have any suggestions for
> > > how to make this work? I'd rather not weaken the sandbox for this
> > > process just so that it can set this one xattr.
> >
> > I'd be willing to move from requiring CAP_SYS_ADMIN to performing a
> > SELinux permission check (either FILE__RELABELFROM or a new one), but
> > I'd like the Android folks to chime in here. Maybe you can ping them
> > through other channels since they haven't responded yet.
>
> I contacted them separately and they are not interested in relaxing
> the requirements and also said that the kernel shouldn't have any
> knowledge of the sehash xattr. So I guess we can just drop this.
Ok. Setting of security.sehash is optional so you can always just
leave it disabled. Only downside is it will then have to walk the
entire directory tree each time to check the labels.
prev parent reply other threads:[~2020-06-12 12:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-01 7:29 [PATCH] selinux: Allow file owner to set "security.sehash" Chirantan Ekbote
2020-06-01 12:42 ` Stephen Smalley
2020-06-05 6:21 ` Chirantan Ekbote
2020-06-05 12:23 ` Stephen Smalley
2020-06-05 12:31 ` Stephen Smalley
2020-06-12 3:59 ` Chirantan Ekbote
2020-06-12 12:40 ` Stephen Smalley [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAEjxPJ5UtA7ixPd0Je6tMgBuykqo_tJDp-gRDY89M--9dQb_3A@mail.gmail.com \
--to=stephen.smalley.work@gmail.com \
--cc=chirantan@chromium.org \
--cc=dgreid@chromium.org \
--cc=eparis@parisplace.org \
--cc=jeffv@google.com \
--cc=nnk@google.com \
--cc=paul@paul-moore.com \
--cc=selinux@vger.kernel.org \
--cc=suleiman@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).