Re: User home directory creation with useradd (rhbz#217441)

[Casey Schaufler <casey@schaufler-ca.com>]

--- Linda Knippers <linda.knippers@hp.com> wrote:


> I don't want more stuff in semanage.  We should be
> able to do it from
> useradd, and from one role.  Right now its a multi
> step operation and
> we can't run useradd and semanage from the same
> role.  Only sysadm_r
> can run useradd and only secadm_r can run semanage
> with the current
> MLS policy.

While this is inconvenient, it is consistant
with the separation of roles. You might want
a role explictitly for this function.
Experiance on other systems has been that
neither the secadm nor the sysadm roles are
sufficient for adding a user by themselves,
nor should they be.

> I've also noticed that only secadm_r can change the
> selinux context
> of a file (makes sense) but secadm_r can't change
> the mode bits of
> the same file, only sysadm_r can.  That doesn't make
> sense to me.

When roles are defined in the context of an
implementaion logical associations don't always
apply. Since SELinux and the policies it
enforces are implemented as an adjunct to the
traditional mechanisms binding a relationship
to their administration is challanging.

> I don't know if that's a bug, a feature or a
> configuration problem
> on my system (and is somewhat off-topic) but its
> another example of
> illogical behavior.

It's illogical only in the context of security
policy integration. Each set of policies are
completely consistant, however the differences
become evident when placed in such proximity.

> Seems like secadm_r can do
> SELinux things but
> not other security administration unrelated to
> SELinux, and that
> makes SELinux look like a wart rather than an
> integrated feature.

Indeed, but take heart as this problem has
come up with Unix MLS systems as well. We
actually dropped the active persuit of roles
in one system because there just didn't seem
to be a useful separation between the system
and security admins, with the exception of
the auditor, which we kept.

> Ok, here's another example.  secadm_r can manage
> policy but can't
> 'touch /.autorelabel', only sysadm_r can do that.

You are seeing the reality of implementation
getting in the way of behavior matching what
a "designed" system ought to do. There are
ways to fix this, but they're expensive and
probably not viable upstream (yet).

So, I don't see that you're going to have
much luck addressing these issues in the
short term as they are artifacts of the
implementation. You might do well to put
some effort into explaining why these
behaviors are rational and necessary in the
context of role separation.


Casey Schaufler
casey@schaufler-ca.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.