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).
> 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;
> > 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;
and this got me my first real progress - 'id -Z' now shows:
system_u:CDTml_high2local_r:unconfined_t:s0
> > 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.
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
};
This didn't get me any farther, though.
Do I need to widen the roles associated with CDTml_high2local_u at login?
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....)
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
