<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 4/9/14, 11:50 AM, Jan Lieskovsky
      wrote:<br>
    </div>
    <blockquote
      cite="mid:653389329.2715955.1397058648212.JavaMail.zimbra@redhat.com"
      type="cite">
      <pre wrap="">----- Original Message -----
</pre>
      <blockquote type="cite" style="color: #000000;">
        <pre wrap=""><span class="moz-txt-citetags">&gt; </span>From: "Trevor Vaughan" 
<span class="moz-txt-citetags">&gt; </span>Sent: Wednesday, April 9, 2014 2:45:05 AM
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>I thought that, functionally, /etc/passwd and gorup needed to be 0644 for
<span class="moz-txt-citetags">&gt; </span>most applications to function correctly. Things may have changed since the
<span class="moz-txt-citetags">&gt; </span>last time I tried it but I seem to remember PAM not being able to find my
<span class="moz-txt-citetags">&gt; </span>home directory when I tried to do this once before.
</pre>
      </blockquote>
      <pre wrap="">AFAICT world-readable permissions are still required on <i class="moz-txt-slash"><span class="moz-txt-tag">/</span>etc<span class="moz-txt-tag">/</span></i>{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:
  <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.fedoraproject.org/pipermail/devel/2014-April/197361.html">https://lists.fedoraproject.org/pipermail/devel/2014-April/197361.html</a> (FreeIPA / LDAP case)
  <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.fedoraproject.org/pipermail/devel/2014-April/197354.html">https://lists.fedoraproject.org/pipermail/devel/2014-April/197354.html</a> (VM case)

Not sure how much likely it is some organization would want to use group
delegation on Red Hat Enterprise Linux:
  <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lwn.net/Articles/487620/">https://lwn.net/Articles/487620/</a>
  <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://adam.younglogic.com/2011/09/group-delegation-in-unix/">http://adam.younglogic.com/2011/09/group-delegation-in-unix/</a>

(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.</pre>
    </blockquote>
    <br>
    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.<br>
    <br>
    Ack.<br>
  </body>
</html>