Hello all,
I have run into a snag while trying to setup su to automatically do a user
context switch through PAM (pam_selinux) while UBAC is active.
If you exempt sysadm_su_t from certain UBAC constraints, you will soon end up
in a situation where you have to deal with su running in root:..:sysadm_su_t
while the forked child process runs in whatever context the Linux user is
mapped to, thus you automatically hit u1 != u2 and since only ubac_constrained
types are involed, most operations will fail when dealing with the parent
process (or its resources).
I am at a loose how to further deal with this, unfortunately.
If you put the target seuser type (e.g. user_t) in permissive or exempt it
from all UBAC constraints, it will work perfectly. But that's obviously not a
solution.
Since the constraints are wired in such a way that the participation of the
system_u user also satisfies the constraint, one idea would be to somehow
force su through that one while making sure that the context is /always/
dropped to a proper user context or the login fails -- which can be done
through PAM. But all this feels like a bandaid/hack and not a proper solution
and brings its own kind of problems.
So I wanted to kindly ask for help / suggestions on how to solve this?
IMHO, having su change the context properly to what the user is mapped to, is
also something that from a security perspective is desirable since otherwise
you end up being logged in as an unprivileged Linux user but have a rather
(over-)privileged context active with no way of changing that.
And from the UBAC perspective, I think it is quite necessary to at least have
something like su do a proper switch since you will want all your files you
create have the proper user context (or remember manually resetting contexts).
Just two advantages from the top of my head.
Thanks in advance for taking the time and your patience. :)
With Kind Regards from Germany
Matthias Dahl
--
Dipl.-Inf. (FH) Matthias Dahl | Software Engineer | binary-island.eu
services: custom software [desktop, mobile, web], server administration
On Fri, Jul 31, 2015 at 04:47:34PM +0200, Matthias Dahl wrote:
> Hello all,
>
> I have run into a snag while trying to setup su to automatically do a user
> context switch through PAM (pam_selinux) while UBAC is active.
>
> If you exempt sysadm_su_t from certain UBAC constraints, you will soon end up
> in a situation where you have to deal with su running in root:..:sysadm_su_t
> while the forked child process runs in whatever context the Linux user is
> mapped to, thus you automatically hit u1 != u2 and since only ubac_constrained
> types are involed, most operations will fail when dealing with the parent
> process (or its resources).
>
> I am at a loose how to further deal with this, unfortunately.
>
> If you put the target seuser type (e.g. user_t) in permissive or exempt it
> from all UBAC constraints, it will work perfectly. But that's obviously not a
> solution.
>
> Since the constraints are wired in such a way that the participation of the
> system_u user also satisfies the constraint, one idea would be to somehow
> force su through that one while making sure that the context is /always/
> dropped to a proper user context or the login fails -- which can be done
> through PAM. But all this feels like a bandaid/hack and not a proper solution
> and brings its own kind of problems.
>
> So I wanted to kindly ask for help / suggestions on how to solve this?
>
> IMHO, having su change the context properly to what the user is mapped to, is
> also something that from a security perspective is desirable since otherwise
> you end up being logged in as an unprivileged Linux user but have a rather
> (over-)privileged context active with no way of changing that.
>
> And from the UBAC perspective, I think it is quite necessary to at least have
> something like su do a proper switch since you will want all your files you
> create have the proper user context (or remember manually resetting contexts).
>
> Just two advantages from the top of my head.
>
> Thanks in advance for taking the time and your patience. :)
>
> With Kind Regards from Germany
> Matthias Dahl
Yeah, this is kind of a problem for me too. I frequently just do things
as sysadm_t and restorecon -F but I really dislike that method.
run_init pipes stuff back and forth between the parent and child ttys
because otherwise the fd use permission would be required everywhere.
Maybe su could do something similar?
You are definitely right tho, there needs to be a better method than
ssh otheruser at localhost. I'd be interested to hear other solutions,
especially from people who use MLS since I imagine that would be an even
bigger can of worms.
-- Jason