Configuring MLS with a daemon operating at multiple sensitivities

Configuring MLS with a daemon operating at multiple sensitivities

[Paul Tagliamonte]

Hey SELinux fans,

I've been playing with MLS on a test box. The "read down/write up"
model makes total sense, but i'm running up against an odd problem set
and trying to figure out how to best work this into an SELinux policy
/ configuration.

I'm interested in having a demon that operates at multiple sensitivity
levels depending on the security context of the peer network
connection (within the same process, ideally, otherwise maybe
threads?).

I'm able to use NetLabel and CIPSO to mark packets with the desired
sensitivity level, and I'm able to get that level via `getpeercon`
during a network connection, but that connection's context hasn't been
dominated by my process's. I'd like to either get that "combined"
context (for instance, if my daemon is s0-s3:c1.c3 and the peer
connection is s2-s15:c3, I'd like to see the value `s2.c3`), or to
actually assume that role (to prevent reading/writing where it's not
supposed to).

Has anyone done something like this before? I have to imagine yes --
but a lot of the docs out there are for things like HTTP Servers,
where you can operate at a high sensitivity for everyone, since the
only data you're writing out is high sensitivity data, and you can
read/serve any other data.

I'm looking for an example where based on categories, the HTTP Server
will only serve files contained within the peer's context's
categories.

    paultag

Re: Configuring MLS with a daemon operating at multiple sensitivities

[Mike Palmiotto]

On Thu, May 14, 2020 at 8:45 AM Paul Tagliamonte <paultag@debian.org> wrote:
>
> Hey SELinux fans,
>
> I've been playing with MLS on a test box. The "read down/write up"
> model makes total sense, but i'm running up against an odd problem set
> and trying to figure out how to best work this into an SELinux policy
> / configuration.
>
> I'm interested in having a demon that operates at multiple sensitivity
> levels depending on the security context of the peer network
> connection (within the same process, ideally, otherwise maybe
> threads?).
>
> I'm able to use NetLabel and CIPSO to mark packets with the desired
> sensitivity level, and I'm able to get that level via `getpeercon`
> during a network connection, but that connection's context hasn't been
> dominated by my process's. I'd like to either get that "combined"
> context (for instance, if my daemon is s0-s3:c1.c3 and the peer
> connection is s2-s15:c3, I'd like to see the value `s2.c3`), or to
> actually assume that role (to prevent reading/writing where it's not
> supposed to).

Joshua Brindle recently contributed a change that may get you what you want:
https://github.com/SELinuxProject/selinux/commit/9ba35fe8c280b7c91ec65b138d9f13e44ededaa9

Here is the corresponding kernel change:
https://github.com/torvalds/linux/commit/42345b68c2e3e2b6549fc34b937ff44240dfc3b6

The kernel change is in 5.5+ it seems, so you'll probably want to use
libsepol in your application.

Hope this helps.
-- 
Mike Palmiotto
https://crunchydata.com

Re: Configuring MLS with a daemon operating at multiple sensitivities

[Paul Tagliamonte]

Hey there Mike,

Incredible! This is very helpful, thank you very much! I think this is
the missing building block I need.

Have a great day, and thank you to Josh!

   paultag


On Thu, May 14, 2020 at 9:56 AM Mike Palmiotto
<mike.palmiotto@crunchydata.com> wrote:
>
> On Thu, May 14, 2020 at 8:45 AM Paul Tagliamonte <paultag@debian.org> wrote:
> >
> > Hey SELinux fans,
> >
> > I've been playing with MLS on a test box. The "read down/write up"
> > model makes total sense, but i'm running up against an odd problem set
> > and trying to figure out how to best work this into an SELinux policy
> > / configuration.
> >
> > I'm interested in having a demon that operates at multiple sensitivity
> > levels depending on the security context of the peer network
> > connection (within the same process, ideally, otherwise maybe
> > threads?).
> >
> > I'm able to use NetLabel and CIPSO to mark packets with the desired
> > sensitivity level, and I'm able to get that level via `getpeercon`
> > during a network connection, but that connection's context hasn't been
> > dominated by my process's. I'd like to either get that "combined"
> > context (for instance, if my daemon is s0-s3:c1.c3 and the peer
> > connection is s2-s15:c3, I'd like to see the value `s2.c3`), or to
> > actually assume that role (to prevent reading/writing where it's not
> > supposed to).
>
> Joshua Brindle recently contributed a change that may get you what you want:
> https://github.com/SELinuxProject/selinux/commit/9ba35fe8c280b7c91ec65b138d9f13e44ededaa9
>
> Here is the corresponding kernel change:
> https://github.com/torvalds/linux/commit/42345b68c2e3e2b6549fc34b937ff44240dfc3b6
>
> The kernel change is in 5.5+ it seems, so you'll probably want to use
> libsepol in your application.
>
> Hope this helps.
> --
> Mike Palmiotto
> https://crunchydata.com



-- 
:wq

Re: Configuring MLS with a daemon operating at multiple sensitivities

[Stephen Smalley]

On Thu, May 14, 2020 at 10:01 AM Paul Tagliamonte <paultag@debian.org> wrote:
>
> Hey there Mike,
>
> Incredible! This is very helpful, thank you very much! I think this is
> the missing building block I need.
>
> Have a great day, and thank you to Josh!

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.  Or your
daemon can just use setcon(3) directly if allowed by policy.

Re: Configuring MLS with a daemon operating at multiple sensitivities

[Paul Tagliamonte]

> 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?

The use-case here is to allow an RPC server to listen to network
traffic, and when properly authenticated, raise the sensitivity level
and category as required, both so the RPC server can logically
handle access controls (not shocked the crunchy folks hit this first)
as well as a system level protection in case there's a slip up and
the server attempts to read a secure file (less urgent but still
very nice to have!).

I'm very much still learning the MLS ropes here, so if someone
sees me hurtling to the edge of a cliff, do let me know!


-- 
:wq

Re: Configuring MLS with a daemon operating at multiple sensitivities

[Stephen Smalley]

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. Up to you as to which model works for your use
case.  Originally SELinux only supported setexeccon(3) but setcon(3)
was added particularly for MLS users and has since been leveraged
elsewhere.  mod_selinux uses setcon(3).  xinetd LABELED uses
setexeccon(3) since it was already exec'ing a separate child daemon.

> The use-case here is to allow an RPC server to listen to network
> traffic, and when properly authenticated, raise the sensitivity level
> and category as required, both so the RPC server can logically
> handle access controls (not shocked the crunchy folks hit this first)
> as well as a system level protection in case there's a slip up and
> the server attempts to read a secure file (less urgent but still
> very nice to have!).
>
> I'm very much still learning the MLS ropes here, so if someone
> sees me hurtling to the edge of a cliff, do let me know!

Re: Configuring MLS with a daemon operating at multiple sensitivities

[Paul Moore]

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