SELinux on btrfs

SELinux on btrfs

[Michael Schuerig]

I'm currently considering to use SELinux on an existing system with 
btrfs filesystems. This would be my first with SELinux and I wouldn't 
expect everything to go smoothly. I'm already aware that SELinux's 
automatic labelling of files is not aware of subvolumes[*]. I already 
have quite a few read-only snapshots that I don't want to forfeit, 
however, I'm not at all sure how SELinux would interact with them.

Are there any other considerations I ought to be aware of?

Michael


[*] https://wiki.debian.org/SELinux/Setup#btrfs
-- 
Michael Schuerig
mailto:michael@schuerig.de
http://www.schuerig.de/michael/

Re: SELinux on btrfs

[Chris Murphy]

>  I'm already aware that SELinux's automatic labelling of files is not aware of subvolumes[*]. 
> [*] https://wiki.debian.org/SELinux/Setup#btrfs

I'm not sure exactly what it means since there is always a subvolume (ID 5), and I don't understand why autorelabel behavior would differ from manually running fixfiles or restorecon. 

In any case, I just obliterated the labeling in /boot which is a Btrfs subvolume mounted at /boot. I then ran "restorecon -Rv /" and this finds the problems in /boot and fixes them. So I obliterated the labels in /boot again, and then did "touch /.autorelabel; reboot" and again /boot is fixed up.

*shrug* Maybe the issue is labeling unmounted subvolumes, as if they're not treated as folders? Nope, if I snapshot /boot as /boot/.bootsnap, and then only mess up the labels in .bootsnap, and then run a restorecon -Rv on /boot, it goes into .bootsnap and fixes its labels. So that's not it either.

> I already have quite a few read-only snapshots that I don't want to forfeit, however, I'm not at all sure how SELinux would interact with them.


If the default policy mismatches with the file context, the relabel or restorecon will want to change the context to the default, but won't be able to because it's a read-only subvolume. I merely get a non-fatal:

restorecon set context /boot/.bootsnap/grub2->system_u:object_r:boot_t:s0 failed:'Read-only file system'

And it proceeds to the next file.

This is not Btrfs specific, but is about autorelabeling, and better ways to go about it.
http://danwalsh.livejournal.com/38157.html



Chris Murphy

Re: SELinux on btrfs

[Russell Coker]

On Sat, 12 Apr 2014 10:15:25 Chris Murphy wrote:
> >  I'm already aware that SELinux's automatic labelling of files is not
> >  aware of subvolumes[*].> 
> > [*] https://wiki.debian.org/SELinux/Setup#btrfs
> 
> I'm not sure exactly what it means since there is always a subvolume (ID 5),
> and I don't understand why autorelabel behavior would differ from manually
> running fixfiles or restorecon.

When you initially setup SE Linux on Debian you run the command "selinux-
activate" which configures GRUB and creates a 0 byte file named /.autorelabel .

On boot if /.autorelabel is detected (as it will on a first install of SE Linux 
or any time you have a serious labelling problem you want to fix) then a script 
will run that labels all files and reboots the system (to make daemons run with 
the correct context).  The script in question is not aware of subvolumes, so 
if you have writable subvolumes they won't be labelled.  So you just run 
"restorecon -R /subvol" to fix it.

I'm not sure whether fixfiles stops at "mount points" which includes subvols, 
restorecon -R shouldn't.

Note that I gave the full explanation for the lurkers.

> > I already have quite a few read-only snapshots that I don't want to
> > forfeit, however, I'm not at all sure how SELinux would interact with
> > them.
> If the default policy mismatches with the file context, the relabel or
> restorecon will want to change the context to the default, but won't be
> able to because it's a read-only subvolume. I merely get a non-fatal:
> 
> restorecon set context /boot/.bootsnap/grub2->system_u:object_r:boot_t:s0
> failed:'Read-only file system'
> 
> And it proceeds to the next file.

Those read-only files should have the type file_t and be readable by the 
sysadmin.  If you want a read-only filesystem that is correctly labelled you 
can make a read-write snapshot, label it, and then make a read-only snapshot 
of the new snapshot.


As an aside, BTRFS and SE Linux work really well together for me.  Much better 
than ZFS and SE Linux.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: SELinux on btrfs

[Chris Murphy]

On Apr 30, 2014, at 2:01 AM, Russell Coker <russell@coker.com.au> wrote:

> On Sat, 12 Apr 2014 10:15:25 Chris Murphy wrote:
>>> I'm already aware that SELinux's automatic labelling of files is not
>>> aware of subvolumes[*].> 
>>> [*] https://wiki.debian.org/SELinux/Setup#btrfs
>> 
>> I'm not sure exactly what it means since there is always a subvolume (ID 5),
>> and I don't understand why autorelabel behavior would differ from manually
>> running fixfiles or restorecon.
> 
> When you initially setup SE Linux on Debian you run the command "selinux-
> activate" which configures GRUB and creates a 0 byte file named /.autorelabel .
> 
> On boot if /.autorelabel is detected (as it will on a first install of SE Linux 
> or any time you have a serious labelling problem you want to fix) then a script 
> will run that labels all files and reboots the system (to make daemons run with 
> the correct context).  The script in question is not aware of subvolumes, so 
> if you have writable subvolumes they won't be labelled.  

That has not been my experience. I changed /boot files to have the wrong selinux labels, set .autorelabel, rebooted, and those files were fixed despite /boot being a mount point for a btrfs subvolume named boot located at the top level of the file system, and mounted with an fstab using subvol=boot option.

I can see how unmounted subvolumes won't be visible to any scripts or even restorecon, so maybe that's what's being referred to?


Chris Murphy

Re: SELinux on btrfs

[Russell Coker]

On Thu, 1 May 2014, Chris Murphy <lists@colorremedies.com> wrote:
> That has not been my experience. I changed /boot files to have the wrong
> selinux labels, set .autorelabel, rebooted, and those files were fixed
> despite /boot being a mount point for a btrfs subvolume named boot located
> at the top level of the file system, and mounted with an fstab using
> subvol=boot option.
> 
> I can see how unmounted subvolumes won't be visible to any scripts or even
> restorecon, so maybe that's what's being referred to?

Yes I believe that the problem is anything that looks like a separate 
filesystem to stat() but doesn't have an entry in /proc/mounts.  So if you 
mount the subvols separately then there's no problem.

Another thing is that if the subvols aren't needed for booting (IE /home) then 
you can just manually label them either before or after the autorelabel boot.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/