AppArmor for Fedora

[Robert Locke]

On Tue, 2007-08-28 at 13:11 +0930, Tim wrote:
> On Mon, 2007-08-27 at 21:55 +0100, Alan Cox wrote:
> > The passwd file isn't considered secret in any way. Its public
> > readable data. The /etc/shadow file holds passwords and is root only.
> 
> I thought that's only because we, now, have passwords stored in another
> location.  It used to contain passwords.  Maybe it still does with some
> distros.
> 
> ll /etc/passwd
> -rw-r--r-- 1 root root 2175 2007-08-19 15:56 /etc/passwd
> 
> Not quite "root only."  Sure, only root can change it, but others can
> read it.
> 

Tim,

/etc/passwd has always been "universally" readable.  As a quick example,
note your use of "ll" which is really "ls -l" and the fact that the
third and fourth columns are displaying "names" of the user and group
associated with that file.  The reality is that the "names" are not
stored on disk, but rather their numeric representation: uid and gid.
In order for the ls command to display a name, it needs to "look up" the
user's name associated with the uid it got from the filesystem.  Where
is this "mapping" of uid and username kept?  Yep, /etc/passed.
Likewise, /etc/group is universally readable to allow lookups of gid to
group name.

The general consensus has always been that the "information" kept
in /etc/passwd and /etc/group are considered "public" information.
Passwords have been "moved" to a "private" file called /etc/shadow
(and /etc/gshadow), because of the potential for "dictionary attacks" on
the encrypted password if all users could access that too.  Look at
"pwconv" and "pwunconv"....

But how public do we really want to be, even with the /etc/passwd fields
that remain?  While most authenticated, interactive users on my system
might need to access /etc/passwd to get proper output from /bin/ls, do
all my daemons/services running in the background need that access?
Does my DNS server really need to "look up" anything in /etc/passwd?
So, as this thread started, these MAC-level security layers allow me to
create more granularity in restricting users and services, but now in a
"central" policy that can be "role" based....

HTH,

--Rob