Petr Lautrbach <plautrba@xxxxxxxxxx> writes:
> 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.
Thanks. So just a warning message. Might be possible to only log it if
debug is enabled?
>
>
>>> 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
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
