On Mon, Feb 18, 2019 at 07:07:33PM -0500, Stephen Smalley wrote:
> On Mon, Feb 18, 2019, 2:09 AM Dominick Grift <dac.override@gmail.com wrote:
> 
> > 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
> >
> 
> I don't think so. object_r has always been handled specially. The kernel
> ignores the role-type definition for it and always exempts contexts that
> contain it from user-role, role-type, and user-range restrictions. We
> didn't use to include it in the policy at all; I think CIL does but we only
> generate a stub in the kernel policy with the role name and value but no
> types and the kernel ignores it. What exactly breaks with pam_selinux?
> 

Tried it again and this time I tried to run install_selinux.sh with selinux disabled (previously i did not bother to boot with selinux disabled)

Now I think I see what you were seeing:

1. setfiles is called in install_selinux.sh but it does not relabel when selinux is disabled
2. the system is misabeled and when you boot, that prompts an autorelabel (don't what does that but maybe systemd) which ,for some reason, does not work either even though it looks like its doing something
3. system does not start properly (even in permissive mode) because it looks like systemd can't compute a valid context using the mislabeled /sbin/init

This, i think, would address that:

1. dont try to run setfiles in install_selinux.sh because it does not work in the scenario where you run install_selinux.sh when selinux is disabled (audit actually prints an FS_RELABEL event but nothing is relabeled)
2. in /etc/selinux/config use SELINUX=permissive instead of SELINUX=enforcing (it needs to relabel in permissive mode in the next step)
3. echo '-F' > /.autorelabel

When all is said and done I still hit the issue where I am not able to log into the system in enforcing mode:

Feb 19 12:05:04 myguest login[1175]: pam_selinux(login:session): Setting file context "user_u:object_r:base_t" failed for /dev/ttyS0: Operation not supported

> 
> > >
> > >> > 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?
> >
> > 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.
> >
> > >
> > >> The `install_policy.sh` script should probably also do a bash file test
> > for `checkpolicy` and fail gracefully if its not found
> >
> > --
> > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> > Dominick Grift
> >

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift