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

[Petr Lautrbach <plautrba@redhat.com>]

Dominick Grift <dac.override@gmail.com> writes:

> Paul Moore <paul@paul-moore.com> writes:
>
>> 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 ... ?
>
> Yes, looks like it
>
>>
>>> > 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`

"sshd_net_t" is really hardcoded as a fallback but
ssh_selinux_change_context("sshd_net_t"); is not a fatal 
operation.
If it fails it just logs a debug message and the type of the 
process
stays unaffected - by default it's sshd_t

I believe that openssh_context is not necessary if you don't mind 
or
want to use different type for privsep preauth sshd processes.


>> Petr, what's the deal with ssh on Fedora?
>
> I wonder whether it would be possible (and feasible) to not 
> transition on
> privsep_preauth at all *unless* a privsep preauth type is 
> specified in
> openssh_context.
>
> Currently it falls back to a hardcoded type to transition to if
> openssh_contexts does not exist.
>
> Then again, i would not want to risk breaking or regressing some 
> of the nice
> functionality openssh in fedora has for selinux. It's state is 
> currently
> very good even compared to RHEL.

I think it's feasible without a big risk. 

https://bugzilla.redhat.com/show_bug.cgi?id=1678695

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