Re: Defining SELinux users, "Unable to get valid context...". Help!

[Dominick Grift <dominick.grift@defensec.nl>]

Peter Whittaker <peterwhittaker@sphyrnasecurity.com> writes:

> On Sat, Feb 13, 2021 at 2:24 AM Dominick Grift
> <dominick.grift@defensec.nl> wrote:
>> Peter Whittaker <peterwhittaker@sphyrnasecurity.com> writes:
>> > On Fri, Feb 12, 2021 at 4:52 PM Dominick Grift
>> > <dominick.grift@defensec.nl> wrote:
>> >> Peter Whittaker <peterwhittaker@sphyrnasecurity.com> writes:
>> >> > On Fri, Feb 12, 2021 at 2:58 AM Dominick Grift
>> >> > <dominick.grift@defensec.nl> wrote:
>> >> >> Dominick Grift <dominick.grift@defensec.nl> writes:
>> >> >> > Peter Whittaker <peterwhittaker@sphyrnasecurity.com> writes:
>> >> >> >>     BLUF: Logging in via SSH or directly at the console results
>> >> >> >>     in "Unable to get valid context...". Help! Much info included.
>>
>> You missed a fundamental type attribute association:
>>
>> type xferHigh2Local_t, CDTml_types, userdomain, process_user_target;
>>
>> It seems that you did not associate your process types with "domain":
>>
>> typeattribute xferHigh2Local_t domain;
>>
>> See if adding that helps
>
> It didn't - but! The failure motivated me to dive more deeply back
> into /var/log/audit/audit.log, wherein I noticed that the desired user
> context has been being computed correctly since sometime yesterday
> (15:29:25 EST, in fact) - but SSH logins were still failing to assign
> that context. So I tried a console login and it worked (I've not made
> any console related changes since you started helping me with this).

Okay but all processes should alway's associate with the domain attribute

>
> Progress: The desired context is properly computed and assigned, at
> least with console (local) login. This leaves me two major items to
> figure out:
>
>     1. Of the changes I have applied over the last 1-3 days,
>         what is the minimum set required to achieve this? My
>         immediate future includes bisection.

Yes i guess work your way back and see...

>
>      2. Why doesn't it work with SSH, when it does work with
>           the console (yes, the ssh_sysadm_login is on)?

see if the ssh daemon runs with the expected:
system_u:system_r:sshd_t:s0 context (ps auxZ | grep ssh)

then doubt check that
/etc/selinux/targeted/contexts/users/CDTml_high2local_u has:
system_r:sshd_t:s0 CDTml_high2local_r:xferHigh2Local_t:s0

And use sesearch to verify that the following queries return:

sesearch -A -s sshd_t -t xferHigh2Local_t -c process -p transition
sesearch -A -s xferHigh2Local_t bin_t -c file -p entrypoint
sesearch -A -s xferHigh2Local_t shell_exec_t -c file -p entrypoint

Also, just in case, try in permissive mode to see if that changes
anything (unlikely but worth a try)

>
> I've read that the latter may have to do with network labelling and/or
> default network context, I may need to explore that.

I dont think that is related

>
> All suggestions welcome!
>
> Thanks! Progress restores optimism.
>
> P

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift