On Sat, 6 Feb 2010, Guillem Jover <[email protected]> wrote: > Ok, so this is my basic understanding of how SE Linux works here (my > terminology might not be accurate), please correct were appropriate. > AFAICS there's at least two ways to apply a context to a file, one is > to set the current file system context for new created objects (via > setfscreatecon) and the other is to explicitly set the context for an > existing file (via setfilecon and friends). Letting a file with the > default context should not reduce the security, it might just not allow > others to access it.
If you don't do anything special then the default context for the created file will be based on the context of the directory that it is created in. The default if there is no specific policy is for the type to match the type of the directory. There can be special policy saying "when a process of domain X creates a file in directory type Y then use type Z". In addition a process can request that a certain context be used for creating a file, the policy can deny such a request or deny it based on the type of object being created. After a filesystem object is created it can be relabeled. Leaving a file with a default context can mean that SUID type functionality is not applied, this can mean that privileges are not dropped. > Are the SE Linux file contexts handled like normal file attributes, > that get propagated with rename(2) and only get reset on unlink(2) or > with an explicit SE Linux call? Or are they handled differently and > do get reset on rename(2) (I thought SE Linux was not path based)? rename(2) and link(2) make no difference to the label. unlink(2) doesn't change it either. Access checks are performed on open handles to unlinked files - when a process calls exec() file handles may be closed by SE Linux because the process transitioned to a new domain and is no longer granted access to the file (or isn't permitted to inherit the file handle). fsetfilecon(3) may be called on an unlinked file, as access controls in SE Linux are performed on all accesses if an unlinked file has it's context changed then processes that are accessing it may suddenly get their access denied with EPERM. > (Or I guess in other words are they associated to the inode or the > dentry?) It's always been the Inode. There is no other sane way to do it. > If it's the former then yes the extra setfscreatecon() at the end of > tarobject() does not seem to make sense, if it's the latter we have > an additional problem, as if tarobject gets interrupted and then it > tries to restore the .dpkg-tmp backup then the context will be wrong > for that one as rename(2) would reset the context. rename(2) does not affect the context. -- [email protected] http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
