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

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

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.
>> >
>> > Thanks to Dominick, I have made at least some progress: I can get the
>> > role to transition, but not the user or the process type. Details below.
>
> SNIP

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

>
>> > That rule was already present (it is the only one I really need, these
>> > users will be coming in via SSH only).
>>
>> Okay I dont think you mentioned that before
>
> No, I didn't. I've been testing with both SSH and local login in an
> attempt to determine where the problem might lie.
>
>> > I added process_user_target to the type definition, no effect:
>> >
>> >     type xferHigh2Local_t, CDTml_types, userdomain, process_user_target;
>>
>> I dont think you mentioned this before and I think you also didnt
>> mention that you had userdomain associates with it.
>
> Correct. Oversight on my part.
>
>> > I then added
>> >
>> >     role_transition system_r sshd_exec_t CDTml_high2local_r;
>>
>> That is wrong
>
> OK. I thought so to, thinking that the context/users and default_*
> files would control this, but it did cause a change. Thought it might
> be a useful data point.
>
> Can you validate my assumption re the users and default_* files?
>
>> > and this got me my first real progress - 'id -Z' now shows:
>> >
>> >     system_u:CDTml_high2local_r:unconfined_t:s0
>>
>> Yes but that is wrong
>
> Indeed!
>
>> > What surprises me most is that originally nothing showed up in ausearch.
>> > I suppose this is because either PAM or SSHD is doing the computation
>> > and not logging it in audit.log, but that is just a guess, likely misguided.
>>
>> Yes the computation does not cause any logging
>
> Ah. Unfortunate.
>
>> > However! After that last allow, above, I finally have errors in ausearch,
>> > many repeats of:
>> >
>> >     libsepol.context_from_record: invalid security context:
> snip
>> >
>> > I then expanded the basic allow rule for the CDTml_high2local_r role:
>> >
>> >    role CDTml_high2local_r types {
>> >        sshd_t
>> >        unconfined_t
>> >        xferHigh2Local_t
>> >        xferHigh2Local_exec_t
>> >    };
>>
>> Yes but the above is not right, and so those errors are expected.
>
> OK, that makes sense.
>
>> > This didn't get me any farther, though.
>> >
>> > Do I need to widen the roles associated with CDTml_high2local_u at login?
>>
>> It helps if you post your full policy related to this and also the output
>> of the following:
>>
>> seinfo -xuCDTml_high2local_u
>> seinfo -xrCDTml_high2local_r
>> seinfo -xtxferHigh2Local_t
>
> Attached as seinfosnip. You'll see that the final seinfo output is
> much too broad, I need to narrow down some of the access rules once I
> get basic functionality working.
>
>> That shouldnt matter, but it helps if you post the full policy rather
>> than snippets.
>
> Didn't want to overwhelm things! I've attached the full policy, CDTml.te.
>
>> getconlist:
>> getdefaultcon:
>
> I'll look into those next week.
>
>> There is also a boolean that might affect things (but speculation
>> without a closer look at your policy):
>>
>> ssh_sysadm_login
>
> I removed the bogus role perms and tried again, with that binary set. No effect.
>
> Thanks again!
>
> 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