On 06/09/14 19:04, Stephen Smalley wrote:
On 06/08/2014 10:48 AM, dE wrote:
When a new file is created on a FS which supports security namespace but
the FS is mounted using context= option, then what will be the context
of the newly created file on the FS?
I did exactly this, and next, umount and then mount the FS readonly to
get the getfattr dump to realize the security namespace is not empty
(this came as a surprise).
So, can someone explain what exactly happens in this case?
The kernel lies to you ;)
If SELinux (or another security module that implements the
inode_getsecurity and inode_listsecurity hooks) is enabled, then the
security module gets to report its view of the security.* attributes to
userspace instead of whatever may or may not be stored by the
filesystem. That allows SELinux to handle such requests even for
filesystems that do not natively support the security.* namespace as
well as remap attribute values as needed to deal with removed types or
conversion from non-MLS to MLS policies or various other situations.
Yes, if I mount vfat for e.g. check the xattr using getfattr, there does
exist a security attribute. But these FSs are defined by genfscon.
But about FSs which do support the security namespace (like XFS), and so
do not have a genfscon statement associated to them they but still have
a security namespace value (as reported by the kernel, which lies to
userspace).
Question is -- are these values actually written to the FS or are they
just empty? Things get more confusing cause I get permission denied when
trying to delete the security namespace values.
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
