Stephen Smalley <stephen.smalley@xxxxxxxxx> writes:
On Tue, Feb 19, 2019, 8:21 AM Stephen Smalley
<stephen.smalley@xxxxxxxxx
wrote:
On Tue, Feb 19, 2019, 6:08 AM Dominick Grift
<dac.override@xxxxxxxxx
wrote:
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@xxxxxxxxx
wrote:
>
> > 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
> >
>
> 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
That's a bug in setfiles / libselinux selinux_restorecon. I
thought that
was fixed recently. If selinux is disabled, we should not
exclude
filesystem based on seclabel.
Was it never merged?
https://lore.kernel.org/selinux/20180926151254.1794-1-sds@xxxxxxxxxxxxx/
Apparently it was not merged. Since there was no objection, only a
LGTM
comment I've just merged it.
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
Operation not supported means that the filesystem type isn't
configured
for labeling. Looks like mdp was never updated to include
devtmpfs among
other filesystems.
>
> > >
> > >> > 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
