[PATCH] [shared] When checking permissions on /etc/group and /etc/passwd allow also stronger permissions than just exactly 0644

Shawn Wells shawn at redhat.com
Wed Apr 9 20:11:54 UTC 2014


On 4/9/14, 11:50 AM, Jan Lieskovsky wrote:
> ----- Original Message -----
>> >From: "Trevor Vaughan"
>> >Sent: Wednesday, April 9, 2014 2:45:05 AM
>> >
>> >I thought that, functionally, /etc/passwd and gorup needed to be 0644 for
>> >most applications to function correctly. Things may have changed since the
>> >last time I tried it but I seem to remember PAM not being able to find my
>> >home directory when I tried to do this once before.
> AFAICT world-readable permissions are still required on/etc/{passwd,group}
> majority of the tools to work properly on multi-user accounts system.
>
> I don't have the data for RHEL system instances, but at least for Fedora
> there seems to be use cases where there's just one / root user account
> on the system:
>    https://lists.fedoraproject.org/pipermail/devel/2014-April/197361.html  (FreeIPA / LDAP case)
>    https://lists.fedoraproject.org/pipermail/devel/2014-April/197354.html  (VM case)
>
> Not sure how much likely it is some organization would want to use group
> delegation on Red Hat Enterprise Linux:
>    https://lwn.net/Articles/487620/
>    http://adam.younglogic.com/2011/09/group-delegation-in-unix/
>
> (but theoretically it's possible).
>
> So agree that the proposal would cover minority of product instances (if any).
>
> But from the principle if the user / organization wanted the permissions to be stronger
> (having the groups listing managed via setuid-ed vigroup or some other way) I think
> SCAP content should allow them to do this / count with this use-case too.

As Jan mentioned, some systems (e.g. much of the cross domain appliance 
community) will configure a single user via SELinux and various RBAC 
controls. Such systems don't need world write. People be crazy.... the 
OVAL should allow them to exceed the security requirements if they want 
to. IIRC, sgrubb mentioned the need for super/sub-compliance for USGCB 
level content as well -- so this is something we really should do.

Ack.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20140409/e5416f67/attachment.html>


More information about the scap-security-guide mailing list