All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: Paul Tagliamonte <paultag@debian.org>
Cc: Mike Palmiotto <mike.palmiotto@crunchydata.com>,
	SElinux list <selinux@vger.kernel.org>,
	Stephen Smalley <stephen.smalley.work@gmail.com>
Subject: Re: Configuring MLS with a daemon operating at multiple sensitivities
Date: Thu, 14 May 2020 20:33:57 -0400	[thread overview]
Message-ID: <CAHC9VhSuxnBpJuFEoAgddA-P8DUdqcQjK9taaABTjDB0Y-uVgQ@mail.gmail.com> (raw)
In-Reply-To: <CAEjxPJ7kF-TB22fZmYPuH0jtBTUBzfd=BcKryPs0t-1H+CwN5g@mail.gmail.com>

On Thu, May 14, 2020 at 11:30 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
> On Thu, May 14, 2020 at 10:57 AM Paul Tagliamonte <paultag@debian.org> wrote:
> >
> > > Was computing the MLS label the only part you needed?  With respect to
> > > having the daemon run in the same label as the peer (or the label
> > > derived from the intersection of the peer and the daemon), you may
> > > wish to have a look at mod_selinux for Apache and/or the old xinetd
> > > LABELED option, although neither of those would have included the new
> > > glblub support so you'll have to integrate that yourself.
> >
> > Ah, really helpful pointers, thank you very much!
> >
> > > Or your daemon can just use setcon(3) directly if allowed by policy.
> >
> > My assumption was that I can use the greatest lower bound, and then
> > preform a `setexeccon` and `exec` to transition to the new security
> > context provided I can pass the open fd according to policy (for
> > now -- at least until I can find a better way to restrict a thread -- I'll
> > do some reading in mod_selinux / xinetd). Is this the case, or am
> > I going to wind up in a world of hurt?
>
> setcon(3) would avoid the need for a separate exec but requires more
> trust in the caller ...

One also has to be careful when using setcon() as it only affects the
domain of the running task and not any transient objects that may have
been created and which the task might expect to be able to access
(which of course is the right thing to do).  If it fits within your
model, setexecon()/exec() is easier, safer, etc.

-- 
paul moore
www.paul-moore.com

      reply	other threads:[~2020-05-15  0:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-14 12:45 Configuring MLS with a daemon operating at multiple sensitivities Paul Tagliamonte
2020-05-14 13:55 ` Mike Palmiotto
2020-05-14 14:00   ` Paul Tagliamonte
2020-05-14 14:50     ` Stephen Smalley
2020-05-14 14:57       ` Paul Tagliamonte
2020-05-14 15:29         ` Stephen Smalley
2020-05-15  0:33           ` Paul Moore [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=CAHC9VhSuxnBpJuFEoAgddA-P8DUdqcQjK9taaABTjDB0Y-uVgQ@mail.gmail.com \
    --to=paul@paul-moore.com \
    --cc=mike.palmiotto@crunchydata.com \
    --cc=paultag@debian.org \
    --cc=selinux@vger.kernel.org \
    --cc=stephen.smalley.work@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.