On Thu, 2004-12-02 at 16:55, Aleksandar Milivojevic wrote: > It looks as if SELinux remembers the inode of the file across the > reboots, and uses inode (not file name) to grant or deny access to > files. So if inode changes while SELinux is not running (for example > during installation, or when booted in rescue mode from CD I guess), it > will remember what was the old inode number and block application's > access to the file based on that (and if some other file is assigned > (now free) inode number of the old ntp.conf file, SELinux will allow > application to access it, altough it shouldn't). > > Is above paragraph correct? Is that the way SELinux works? Not exactly. SELinux stores the file security context in an extended attribute of the inode (man 5 attr), and uses that as the basis for security checks. So if you create a file when SELinux is not running, the inode will lack the attribute. When you next boot a SELinux kernel and try to access that file, SELinux will see that it has no attribute, treat it as having a default file context, and typically policy will deny access to that default file context except to privileged processes (to allow them to set the context appropriately while preventing inadvertent leakage or modification of the data content to untrusted processes). > Couple of questions. How to instruct SELinux portion of Linux that some > inodes had changed outside of its controll, so it should update its > internal databases? Am I to expect this every time I boot from CD in > rescue mode and change something? restorecon can be used to restore the context of a file to the typical context associated with that pathname. chcon can be used to set the context to a specific value. fixfiles relabel can be used to check and relabel the entire filesystem. I'd expect that even rescue mode should run with SELinux enabled, but don't know. -- Stephen Smalley <sds@xxxxxxxxxxxxxx> National Security Agency
