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