On Tue, 2007-08-28 at 08:01 -0500, Les Mikesell wrote: > 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. Not everything needs to know about setting SELinux security contexts, as policy can transparently handle many cases based on the creating process' security context, the parent directory security context, and the kind of file. In the case where a single application creates multiple files in the same directory that should be protected differently, the issue is no different than for file modes and ownerships. Just as applications such as useradd have to specify that /etc/passwd and /etc/shadow should be created with different file modes, so they should specify the proper context (or at least preserve context from original). Keep in mind that it is the application that controls where the data flows in that case, and thus application knowledge comes into play with regard to how that data should be protected. When simple policy configuration or modifying the application isn't practical/possible, you have solutions like restorecond, where you can use policy to initially label the file safely (most restrictive label) and then have a userspace component like restorecond relabel the file upon inotify notification of file creation to the more specific label. It doesn't require having the kernel control access based on pathname, which has well known problems. -- Stephen Smalley National Security Agency -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
