AppArmor for Fedora

Les Mikesell lesmikesell at gmail.com
Tue Aug 28 13:01:10 UTC 2007


Robert Locke wrote:
> 
> /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? 

You'd be in pretty bad shape if you couldn't find your own home 
directory and it's generally useful to be able to reference other users 
home directories with the ~user notation.

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

Apache probably does if you serve user directories.  Mail delivery does.

> Does my DNS server really need to "look up" anything in /etc/passwd?

Your DNS server can run chroot and see a fake /etc/passwd if you want.

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

Back to the subject topic, though, the question is whether it is better 
to control access based on filenames or inodes.  Traditionally, the way 
to make atomic changes to unix files has always been to create a new 
file and rename it to the old name.  Anything that has the old file open 
will continue to see the old contents; any subsequent open will get the 
new contents, and the semantics of rename() (since it became a system 
call) ensure that there is never a time when open() will fail to see the 
filename.  However, the replacement file must have a different inode, so 
everything that handles files in the traditional way now needs to know 
about setting SELinux security contexts - which doesn't seem likely.

-- 
   Les Mikesell
     lesmikesell at gmail.com





More information about the users mailing list