Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 119941 - s-c-u support for selinux not consistent with policies
s-c-u support for selinux not consistent with policies
Product: Fedora
Classification: Fedora
Component: system-config-users (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Brent Fox
Depends On:
Blocks: FC2Target
  Show dependency treegraph
Reported: 2004-04-03 14:58 EST by Gene Czarcinski
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-04-19 14:20:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Gene Czarcinski 2004-04-03 14:58:12 EST
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 15:13:16 EST
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 14:08:56 EDT
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 14:20:06 EDT
Widgets should be hidden in system-config-users-1.2.12-3 in Rawhide.
Comment 4 Matthew Miller 2004-04-20 14:57:07 EDT
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.