Peter Whittaker <peterwhittaker@xxxxxxxxxxxxxxxxxxx> writes:
> On Fri, Feb 12, 2021 at 2:58 AM Dominick Grift
> <dominick.grift@xxxxxxxxxxx> wrote:
>> Dominick Grift <dominick.grift@xxxxxxxxxxx> writes:
>> > Peter Whittaker <peterwhittaker@xxxxxxxxxxxxxxxxxxx> 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.
>
>> > A few things that I could find but that are needed for computing
>> > contexts are:
>> >
>> > the login programs need to be allowed to manual transition to the user
>> > type. So for example if you want to login with sshd_t:
>> > allow sshd_t xferHigh2Local_t:process transition;
>
> 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
>
>> In relation to the above, ensure that the xferHigh2Local_t type is
>> associated with the process_user_target typeattribute:
>> typeattribute xferHigh2Local_t process_user_target;
>
> 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.
>
>> > The user type needs to be a bin and shell entry type:
>> > allow xferHigh2Local_t { bin_t shell_exec_t }:file entrypoint;
>
> Also added that, after testing process_user_target, no effect. (So I
> had all three suggestions active.)
>
> I then added
>
> role_transition system_r sshd_exec_t CDTml_high2local_r;
That is wrong
>
> 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
>
>> > There is probably more that i am overlooking but these, i think, are
>> > important part for computation of contexts
>
> Any other suggestions would be most welcome! I am at a loss,
> especially since the
> *_u "types" are not part of the policy but are defined via semanage,
> and I already have
> rules for the _t types, via an existing rules:
>
> allow { sshd_t unconfined_t } xferHigh2Local_t:process transition;
>
> 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
>
> However! After that last allow, above, I finally have errors in ausearch,
> many repeats of:
>
> libsepol.context_from_record: invalid security context:
> "system_u:CDTml_high2local_r:sshd_t:s0"
> libsepol.context_from_record: could not create context structure
> libsepol.context_from_string: could not create context structure
> libsepol.sepol_context_to_sid: could not convert
> system_u:CDTml_high2local_r:sshd_t:s0 to sid
> libsepol.context_from_record: invalid security context:
> "system_u:CDTml_high2local_r:unconfined_t:s0"
> libsepol.context_from_record: could not create context structure
> libsepol.context_from_string: could not create context structure
> libsepol.sepol_context_to_sid: could not convert
> system_u:CDTml_high2local_r:unconfined_t:s0 to sid
>
> 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.
>
> 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
>
> I really am trying to keep them as tight as possible. (Which,
> incidentally, is one
> of the reasons I am using "old school" rules and not CIL: the M4 macros may
> do more than I need them to....)
That shouldnt matter, but it helps if you post the full policy rather
than snippets.
also there are some tools that you can use to verify if a specified
context can be reached.
getconlist:
https://github.com/SELinuxProject/selinux/blob/master/libselinux/utils/getconlist.c
getdefaultcon:
https://github.com/SELinuxProject/selinux/blob/master/libselinux/utils/getdefaultcon.c
There is also a boolean that might affect things (but speculation
without a closer look at your policy):
ssh_sysadm_login
see if setting that to on helps
>
> Thanks,
>
> P
>
> PS apologies to all for the double send of the original, user error (PEBCAD).
>
> Peter Whittaker
> Director, Business Development
> www.SphyrnaSecurity.com
> +1 613 864 5337
--
gpg --locate-keys dominick.grift@xxxxxxxxxxx
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift
