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

[Jan Lieskovsky]

[shared] When checking permissions on /etc/group and /etc/passwd files,
don't require exactly 0644 mode, but allow also systems having
stronger file permissions on these files to meet the tests (IOW make
0644 mode the minimal safe requirement).

Please review.

Thank you && Regards, Jan
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team

[Trevor Vaughan]

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.

I guess this might not be the case if you put all of your uses in LDAP but
then what does it matter that the files are world readable?

Thanks,

Trevor


On Thu, Apr 3, 2014 at 8:26 AM, Jan Lieskovsky <jlieskov(a)redhat.com&gt; wrote:

>  [shared] When checking permissions on /etc/group and /etc/passwd files,
>  don't require exactly 0644 mode, but allow also systems having
>  stronger file permissions on these files to meet the tests (IOW make
>  0644 mode the minimal safe requirement).
>
>  Please review.
>
>  Thank you && Regards, Jan
>  --
>  Jan iankko Lieskovsky / Red Hat Security Technologies Team
>  _______________________________________________
>  scap-security-guide mailing list
>  scap-security-guide(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>
>  

-- 
Trevor Vaughan
Vice President, Onyx Point, Inc
[phone]
tvaughan(a)onyxpoint.com

-- This account not approved for unencrypted proprietary information --

[Jan Lieskovsky]

----- 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.

Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team

>  
>  I guess this might not be the case if you put all of your uses in LDAP but
>  then what does it matter that the files are world readable?
>  
>  Thanks,
>  
>  Trevor
>  
>  
>  On Thu, Apr 3, 2014 at 8:26 AM, Jan Lieskovsky < jlieskov(a)redhat.com > wrote:
>  
>  
>  
>  [shared] When checking permissions on /etc/group and /etc/passwd files,
>  don't require exactly 0644 mode, but allow also systems having
>  stronger file permissions on these files to meet the tests (IOW make
>  0644 mode the minimal safe requirement).
>  
>  Please review.
>  
>  Thank you && Regards, Jan
>  --
>  Jan iankko Lieskovsky / Red Hat Security Technologies Team
>  _______________________________________________
>  scap-security-guide mailing list
>  scap-security-guide(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>  
>  
>  
>  
>  --
>  Trevor Vaughan
>  Vice President, Onyx Point, Inc
>  [phone]
>  tvaughan(a)onyxpoint.com
>  
>  -- This account not approved for unencrypted proprietary information --
>  
>  _______________________________________________
>  scap-security-guide mailing list
>  scap-security-guide(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>

[Shawn Wells]

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.