Re: [PATCH v3] scripts/selinux: add basic mls support to mdp

From: Paul Moore <paul@paul-moore.com>
To: Stephen Smalley <sds@tycho.nsa.gov>,
	selinux@vger.kernel.org, Petr Lautrbach <plautrba@redhat.com>
Cc: Paul Moore <paul@paul-moore.com>
Subject: Re: [PATCH v3] scripts/selinux: add basic mls support to mdp
Date: Sun, 17 Feb 2019 22:12:53 -0500	[thread overview]
Message-ID: <CAHC9VhQsj8UnV=CZ+vkvruB6Nn_W7SzW-W4oTK9=QcJRkfeiJg@mail.gmail.com> (raw)
In-Reply-To: <20190216121256.GB11908@brutus.lan>

On Sat, Feb 16, 2019 at 7:12 AM Dominick Grift <dac.override@gmail.com> wrote:
>
> On Sat, Feb 16, 2019 at 01:04:12PM +0100, Dominick Grift wrote:
> > On Fri, Feb 15, 2019 at 02:48:45PM -0500, Stephen Smalley wrote:
> > <snip>
> >
> > >
> > > Oh, I see: scripts/selinux/install_policy.sh just invokes checkpolicy
> > > without specifying -U / --handle-unknown, so the policy defaults to deny,
> > > and that would indeed render dbus-daemon and systemd broken with that
> > > policy.  Might be as simple to fix as passing -U allow.
> >
> > I have looked a litte into this and here are some observations:
> >
> > 1. You can boot mdp as-is in permissive mode if you use `checkpolicy` with `-U allow`
> >
> > 2. You need *at least* an `/etc/selinux/dummy/seusers` with `__default__:user_u` and an accompanying `/etc/selinux/dummy/contexts/failsafe_context` with `base_r:base_t` to boot mdp in enforcing

Wow.  I didn't expect we would get to this point so quickly.

Originally my plan had been to just merge the mdp changes that Stephen
submitted, and leave the rest for some other time.  Although based on
everything in this thread, it looks like we are really close to having
something that you can build and boot without too many hacks.

> > 3. There is an issue with checkpolicy and object_r:
> >
> > PAM libselinux clients such as `login` try to associate `object_r` with the tty and fail.
> >
> > if you try to append: `role object_r; role object_r types base_t;` to policy.conf and compile that with `checkpolicy` then the `roletype-rule` does *not* end up in the compiled policy for some reason.

This sounds like a bug in checkpolicy ... ?

> > thus, you cannot log in because object_r:base_t is not valid.
> >
> > To hack around this add `default_role * source` rules to policy.conf and recompile.
> >
> > This will allow you to log into the system locally in enforcing mode.
> >
> > 4. I also noticed that fedoras' ssh seems to hardcode `sshd_net_t` for its "privsep" functionality so, while untested, you probably need an `openssh_contexts` with `privsep_preauth=base_t`

Petr, what's the deal with ssh on Fedora?

> The `install_policy.sh` script should probably also do a bash file test for `checkpolicy` and fail gracefully if its not found

-- 
paul moore
www.paul-moore.com