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@xxxxxxxxx
