On 06/10/14 21:11, David Caplan wrote:
-----Original Message-----
From: Selinux [mailto:selinux-bounces@xxxxxxxxxxxxx] On Behalf Of
Stephen Smalley
Sent: Tuesday, June 10, 2014 8:05 AM
To: dE; selinux@xxxxxxxxxxxxx
Subject: Re: Default context with context mount option.
On 06/10/2014 04:16 AM, dE wrote:
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.
It shouldn't be written to the filesystem. You can check by booting
with SELinux disabled (selinux=0 on the kernel command-line or
/etc/selinux/config SELINUX=disabled) and then running getfattr; then
the kernel will just call down to the filesystem code to fetch the
attribute without any interference by the security module. However,
note that this will trigger an automatic filesystem relabel upon reboot
into SELinux to ensure that all files are labeled, which can take some
time.
With regard to removing the security.selinux attributes, SELinux also
prohibits that entirely; see
security/selinux/hooks.c:selinux_inode_removexattr() in the kernel. So
again, to do that, you'd have to boot with SELinux disabled, but it
shouldn't be necessary.
How about creating a file based filesystem image and mounting it with a loop device? You can mount it with context mount options or straight up and easily see changes (or no changes) to the filesystem. That way you don't have to disable selinux and reboot the whole system. You can easily experiment with whichever filesystem types you'd like.
David
Yeah, I did exactly that, but to see the actually xattr on the FS, you
have to disable SELinux, cause get/setxattr works at VFS level; it
queries the kernel for the xattr, and the kernel lies to it via SELinux
(which has attached LSM hooks).
The manual loop mount idea is good to prevent an automatic relabel by
the systemd services, but you have to disable SELinux.
_______________________________________________
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.
