[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: chaning files with selinux and policy targeted enabled



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 epoch ncsc mil>
National Security Agency


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]