Bug 119941 - s-c-u support for selinux not consistent with policies
Summary: s-c-u support for selinux not consistent with policies
Alias: None
Product: Fedora
Classification: Fedora
Component: system-config-users
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Brent Fox
QA Contact:
Depends On:
Blocks: FC2Target
TreeView+ depends on / blocked
Reported: 2004-04-03 19:58 UTC by Gene Czarcinski
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2004-04-19 18:20:06 UTC

Attachments (Terms of Use)

Description Gene Czarcinski 2004-04-03 19:58:12 UTC
Description of problem:

The role(s) selected for selinux when adding a user for "System
Administrator" are not consistent with other stuff.  For example, a
user defined this way should be able to run up2date with a password
prompt for his/her password ... not root's password.  I believe the
roles that need to be assigned are staff_r sysadm_r

Comment 1 Gene Czarcinski 2004-04-03 20:13:16 UTC
I guess s-c-u is still a "work in progress" since the reason it is not
consistent is that it appears that it is not updating the policy.

Comment 2 Brent Fox 2004-04-19 18:08:56 UTC
I just stubbed in the widgets in the hopes that the SELinux handling
would be added to libuser in time.  It looks like that isn't going to
happen, so I'm going to hide those widgets for the time being.

Comment 3 Brent Fox 2004-04-19 18:20:06 UTC
Widgets should be hidden in system-config-users-1.2.12-3 in Rawhide.

Comment 4 Matthew Miller 2004-04-20 18:57:07 UTC
I'm not sure using SELinux roles to determine what password is asked
for is the right approach. Having tools check for SELinux and act
differently has a surprising side-effect -- normally, SELinux acts as
additional limits to standard Unix permissions and authorization, but
this would make SELinux allow users to do things they couldn't
normally. Booting with SE Linux enabled shouldn't give more lenient
access rights than having it disabled.

Making SELinux go both directions can only lead to confusion, and
confusing security policy leads to bad security, no matter how strong
the technical implementation.

Instead, I humbly suggest that auth-as-self access be implemented via
my patch to usermode: bug #86188.

Note You need to log in before you can comment on or make changes to this bug.