Bug 119941

Summary:	s-c-u support for selinux not consistent with policies
Product:	[Fedora] Fedora	Reporter:	Gene Czarcinski <gczarcinski>
Component:	system-config-users	Assignee:	Brent Fox <bfox>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	dwalsh, mattdm
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-04-19 18:20:06 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	114963

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.