Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 119941 - s-c-u support for selinux not consistent with policies
Summary: s-c-u support for selinux not consistent with policies
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: system-config-users
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Brent Fox
QA Contact:
URL:
Whiteboard:
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)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-04-19 18:20:06 UTC
Type: ---
Embargoed:

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.