Dominick Grift <dac.override@xxxxxxxxx> writes:
Paul Moore <paul@xxxxxxxxxxxxxx> writes:
On Sat, Feb 16, 2019 at 7:12 AM Dominick Grift
<dac.override@xxxxxxxxx> 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
