On Fri, Feb 12, 2021 at 4:52 PM Dominick Grift
<dominick.grift@xxxxxxxxxxx> wrote:
> 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.
SNIP
> > 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
Attachment:
seinfosnip
Description: Binary data
Attachment:
CDTml.te
Description: Binary data
