Mailing List Archive

On Tue, Mar 04, 2014 at 09:17:18PM +1100, wraeth wrote:
> Not sure if this is the right list to ask in, but I figure I'll go ahead
> and ask anyway.

It's the right list ;-)

> At the moment I'm currently on the 13.0/desktop/gnome/systemd profile,
> and I'd like to enable SELinux. I know that there is a 13.0/selinux
> profile (as well as the hardened profiles) but I was wondering if
> there's any documentation (or perhaps someone can offer some guidance)
> on doing this while maintaining the current profile.
>
> I've had a look at the SELinux handbook [1], however it only says to
> perform the migration using the profiles (and the 'selinux' use flag is
> always marked as "do not do this yourself").
>
> My concern is that if I were to migrate to the 13.0/selinux profile, I
> would also loose all of the profile default use flags, masks, etc. that
> the current profile enables.
>
> I could go through the time and effort of identifying the changes
> between the profiles, but that would be a lot of work for only a
> potential success (I'd probably end up missing something); besides, I
> don't feel that would be the "right" way to do it.
>
> Any suggestions or pointers would be greatly appreciated.

What you can do is to put the files that are in the
profiles/features/selinux location inside /etc/portage/profile. Make sure
however that you don't overwrite any files you've put in there previously
though (don't want you to lose your own modifications).

Through this, your system will be "as if" you selected your profile with
"/selinux" on it.

We're not creating individual "/selinux" profiles for each and every
possibility (yet), mostly because we're not able to test out all sets of
combinations. In your case for instance, you're using systemd whose support
in SELinux is still rapidly evolving (we're waiting for Fedora to upstream
their patches, and then we take those in).

Wkr,
Sven Vermeulen

Okay, an update:

I'm writing this from my (sorta) SELinux-enabled machine now. :)

There were a few little bumps in the process (you may have seen
something in #gentoo-hardened), but for the most part the
Install/Migrate guide was good.

The two things that I will note I had to do are:

* Rebuild util-linux *
mount, provided by util-linux, does not have the functionality
required by SELinux when coming from a non-hardened stage. In order to
get this installed (without bricking anything) I had to:

emerge -1 libselinux (this will also pull in libsepol)
emerge -1O util-linux (-O required to prevent pols being pulled in)

This should happen just prior to the first reboot (and any initrd's
should be rebuilt to include the new mount binary, i guess).

* Select policy type *
This is more of a note on the documentation (I know it's out of date,
(or at least so the wiki says) but for reference nonetheless). I'm
taking the easy road in and have selected the 'targeted' policy type for
now. Because of this, running ``emerge -uDN @world`` prior to setting
the policy type in /etc/selinux/config causes emerge to attempt to set
the wrong policy, and fail the ebuild. This is in reference to code
listings 2.3 and 2.6 of the SELinux handbook.


Other than that, everything has gone smoothly except for one thing:
during boot, I'm getting:
systemd-remount-fs[733]: mount: /run not mounted or bad option

That being said, once booted, /run *is* mounted with:
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)

The relevant line in fstab is:
tmpfs /run tmpfs mode=0755,nosuid,nodev,context=system_u:object_r:var_run_t 0 0

I'm not sure why this is (current thinking is perhaps a symptom of the
docs being outdated) and the system seems stable for the moment.

There are other errors in the logs (avc denials on udevd, for example)
but I'm not too worried for the moment - I'm remaining in permissive
mode specifically for that reason :)

Thanks to swift for the info on merging the profiles, and any advice or
suggestions on the above would be appreciated! :D

Cheers;
wraeth

On Thu, Mar 06, 2014 at 12:40:21AM +1100, wraeth wrote:
> * Rebuild util-linux *
> mount, provided by util-linux, does not have the functionality
> required by SELinux when coming from a non-hardened stage. In order to
> get this installed (without bricking anything) I had to:
>
> emerge -1 libselinux (this will also pull in libsepol)
> emerge -1O util-linux (-O required to prevent pols being pulled in)
>
> This should happen just prior to the first reboot (and any initrd's
> should be rebuilt to include the new mount binary, i guess).

Wouldn't the package (util-linux) be rebuild anyway? It uses USE=selinux so
the "emerge -uDN world" should rebuild it (with libselinux bindings).

> * Select policy type *
> This is more of a note on the documentation (I know it's out of date,
> (or at least so the wiki says) but for reference nonetheless).

Where on the wiki does it say that? The SELinux handbook is not out of
date. It had an issue if you use 'targeted' as you rightly said but that's a
bug, not due to potentially being outdated. And not having it registered as
a bug on bugs.gentoo.org made it so it took a while before it got properly
noticed (I can read mailinglists from work, but when I can do a bit of
Gentoo development I check the bug list and forget that there were things
mentioned on the mailinglist).

> I'm
> taking the easy road in and have selected the 'targeted' policy type for
> now. Because of this, running ``emerge -uDN @world`` prior to setting
> the policy type in /etc/selinux/config causes emerge to attempt to set
> the wrong policy, and fail the ebuild. This is in reference to code
> listings 2.3 and 2.6 of the SELinux handbook.

Indeed; I've moved the editing of /etc/selinux/config prior to the 'emerge
-uDN world' step.

> Other than that, everything has gone smoothly except for one thing:
> during boot, I'm getting:
> systemd-remount-fs[733]: mount: /run not mounted or bad option
>
> That being said, once booted, /run *is* mounted with:
> tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)
>
> The relevant line in fstab is:
> tmpfs /run tmpfs mode=0755,nosuid,nodev,context=system_u:object_r:var_run_t 0 0
>
> I'm not sure why this is (current thinking is perhaps a symptom of the
> docs being outdated) and the system seems stable for the moment.

Can you check your dmesg or logs? I don't know systemd-remount-fs but
perhaps it's because /run is already mounted and thus it cannot mount it
(without being smart enough to use "-o remount").

If you do something like the following, does the context then appear?

#v+
mount -o remount,context=system_u:object_r:var_run_t /run
#v-

My system gives the following:

#v+
$ mount | grep run
tmpfs on /run type tmpfs (rw,rootcontext=system_u:object_r:var_run_t,seclabel,nosuid,nodev,noexec,relatime)
#v-

Wkr,
Sven Vermeulen

On Thu, 2014-03-06 at 15:15 +0000, Sven Vermeulen wrote:
> On Thu, Mar 06, 2014 at 12:40:21AM +1100, wraeth wrote:
> > * Rebuild util-linux *
> > This should happen just prior to the first reboot (and any initrd's
> > should be rebuilt to include the new mount binary, i guess).
>
> Wouldn't the package (util-linux) be rebuild anyway? It uses USE=selinux so
> the "emerge -uDN world" should rebuild it (with libselinux bindings).

This *would* be done with an `emerge -uDN @world`; however the manual
has you modify your fstab to include mount point contexts (code listing
1.3/1.4/1.8), build the SELinux-enabled kernel (listing 1.7), then
reboot after listing 1.9, with the world update coming in at listing
2.5.

Doing a world update prior to then is advised against as per the note
below listing 1.5 ("Do not rebuild your system right now <snip> pull in
SELinux policies which could make your system unreachable ...").

However, as I experienced following through this, rebooting as
instructed, without rebuilding util-linux, failed to mount the
filesystems as it hasn't been built against libselinux.

As per your comment below about keeping track of where things are
mentioned, I can file this as a bug, too.

> > * Select policy type *
> > This is more of a note on the documentation (I know it's out of date,
> > (or at least so the wiki says) but for reference nonetheless).
>
> Where on the wiki does it say that? The SELinux handbook is not out of
> date. It had an issue if you use 'targeted' as you rightly said but that's a
> bug, not due to potentially being outdated. And not having it registered as
> a bug on bugs.gentoo.org made it so it took a while before it got properly
> noticed (I can read mailinglists from work, but when I can do a bit of
> Gentoo development I check the bug list and forget that there were things
> mentioned on the mailinglist).

I could have sworn that I saw it say somewhere that the documentation
was in need of updating, but now that I'm looking, I can't find it... I
didn't want to file a bug (given my understanding at the time that the
documentation was known to be in need of updating) since it would just
be pointing out what's already known - I just wanted to add my
observation so that whenever changes were made, it would be considered.

That being said, it *was* just a matter of ordering of steps, and it's
now been reported and resolved. :)

> Can you check your dmesg or logs? I don't know systemd-remount-fs but
> perhaps it's because /run is already mounted and thus it cannot mount it
> (without being smart enough to use "-o remount").
>
> If you do something like the following, does the context then appear?
>
> #v+
> mount -o remount,context=system_u:object_r:var_run_t /run
> #v-
>
> My system gives the following:
>
> #v+
> $ mount | grep run
> tmpfs on /run type tmpfs (rw,rootcontext=system_u:object_r:var_run_t,seclabel,nosuid,nodev,noexec,relatime)
> #v-

I had a brief look at this last night but haven't had a look in-depth as
yet. I did notice that there is a point during boot at which it
relabels the /dev and /run filesystems, but the resulting mount point
still does not have the appropriate context. This could be either due
to /run already being mounted, or an issue with the initrd.

I don't have access to that machine at the moment, but I'll investigate
this more thoroughly and see what I can figure out.

Thanks for the help, and I'll let you know what I find.

Cheers;
wraeth

On Thu, 2014-03-06 at 15:15 +0000, Sven Vermeulen wrote:
> Can you check your dmesg or logs? I don't know systemd-remount-fs but
> perhaps it's because /run is already mounted and thus it cannot mount it
> (without being smart enough to use "-o remount").

Service failed remounting the /run filesystem:

nemesis ~ # journalctl -b -u systemd-remount-fs.service
Mar 08 05:33:23 nemesis systemd[1]: Starting Remount Root and Kernel File Systems...
Mar 08 05:33:23 nemesis systemd-remount-fs[700]: mount: /run not mounted or bad option
Mar 08 05:33:23 nemesis systemd-remount-fs[700]: In some cases useful info is found in syslog - try
Mar 08 05:33:23 nemesis systemd-remount-fs[700]: dmesg | tail or so
Mar 08 05:33:23 nemesis systemd-remount-fs[700]: /bin/mount for /run exited with exit status 32.
Mar 08 05:33:23 nemesis systemd[1]: systemd-remount-fs.service: main process exited, code=exited, status=1/FAILURE
Mar 08 05:33:23 nemesis systemd[1]: Failed to start Remount Root and Kernel File Systems.
Mar 08 05:33:23 nemesis systemd[1]: Unit systemd-remount-fs.service entered failed state.


> If you do something like the following, does the context then appear?
>
> #v+
> mount -o remount,context=system_u:object_r:var_run_t /run
> #v-

nemesis ~ # mount -o remount,mode=0755,nosuid,nodev,context=system_u:object_r:var_run_t /run
mount: /run not mounted or bad option
In some cases useful info is found in syslog - try
dmesg | tail or so

nemesis ~ # ls -l /etc/mtab
lrwxrwxrwx. 1 root root 17 Feb 12 11:49 /etc/mtab -> /proc/self/mounts

And the last few lines from dmesg:
[ 166.570640] audit_printk_skb: 117 callbacks suppressed
[ 166.570643] type=1400 audit(1394177766.465:177): avc: denied { read } for pid=2378 comm="gpg2" name="evolution-pgp.7SCJCX" dev="tmpfs" ino=10027 scontext=staff_u:sysadm_r:gpg_t tcontext=system_u:object_r:tmp_t tclass=file
[ 166.570651] type=1400 audit(1394177766.465:178): avc: denied { open } for pid=2378 comm="gpg2" path="/tmp/evolution-pgp.7SCJCX" dev="tmpfs" ino=10027 scontext=staff_u:sysadm_r:gpg_t tcontext=system_u:object_r:tmp_t tclass=file
[ 193.766692] type=1400 audit(1394177795.942:179): avc: denied { sigchld } for pid=1 comm="systemd" scontext=staff_u:sysadm_r:sysadm_dbusd_t tcontext=system_u:system_r:kernel_t tclass=process
[ 246.306818] SELinux: unable to change security options during remount (dev tmpfs, type=tmpfs)

I can't help but notice that the output of the remount here is the same
as that during systemd-remount-fs.service failing during boot. Note
also that SELinux is still in permissive mode - I imagine I'd be going
nowhere fast if I tried booting in enforcing mode at this stage. :)


> My system gives the following:
>
> #v+
> $ mount | grep run
> tmpfs on /run type tmpfs (rw,rootcontext=system_u:object_r:var_run_t,seclabel,nosuid,nodev,noexec,relatime)
> #v-

nemesis ~ # mount | grep run
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)

nemesis ~ # grep run /etc/fstab
tmpfs /run tmpfs remount,mode=0755,nosuid,nodev,context=system_u:object_r:var_run_t 0 0

I also tried remounting with only the options you specified
("remount,context=...") instead of the full set, with the same result.

I'm not sure how to get more information out of the SELinux subsystem in
order to get more information out of it...

Cheers;
wraeth

On Thu, 2014-03-06 at 15:15 +0000, Sven Vermeulen wrote:
> Can you check your dmesg or logs? I don't know systemd-remount-fs but
> perhaps it's because /run is already mounted and thus it cannot mount it
> (without being smart enough to use "-o remount").

Service failed remounting the /run filesystem:

nemesis ~ # journalctl -b -u systemd-remount-fs.service
Mar 08 05:33:23 nemesis systemd[1]: Starting Remount Root and Kernel File Systems...
Mar 08 05:33:23 nemesis systemd-remount-fs[700]: mount: /run not mounted or bad option
Mar 08 05:33:23 nemesis systemd-remount-fs[700]: In some cases useful info is found in syslog - try
Mar 08 05:33:23 nemesis systemd-remount-fs[700]: dmesg | tail or so
Mar 08 05:33:23 nemesis systemd-remount-fs[700]: /bin/mount for /run exited with exit status 32.
Mar 08 05:33:23 nemesis systemd[1]: systemd-remount-fs.service: main process exited, code=exited, status=1/FAILURE
Mar 08 05:33:23 nemesis systemd[1]: Failed to start Remount Root and Kernel File Systems.
Mar 08 05:33:23 nemesis systemd[1]: Unit systemd-remount-fs.service entered failed state.


> If you do something like the following, does the context then appear?
>
> #v+
> mount -o remount,context=system_u:object_r:var_run_t /run
> #v-

nemesis ~ # mount -o remount,mode=0755,nosuid,nodev,context=system_u:object_r:var_run_t /run
mount: /run not mounted or bad option
In some cases useful info is found in syslog - try
dmesg | tail or so

nemesis ~ # ls -l /etc/mtab
lrwxrwxrwx. 1 root root 17 Feb 12 11:49 /etc/mtab -> /proc/self/mounts

And the last few lines from dmesg:
[ 166.570640] audit_printk_skb: 117 callbacks suppressed
[ 166.570643] type=1400 audit(1394177766.465:177): avc: denied { read } for pid=2378 comm="gpg2" name="evolution-pgp.7SCJCX" dev="tmpfs" ino=10027 scontext=staff_u:sysadm_r:gpg_t tcontext=system_u:object_r:tmp_t tclass=file
[ 166.570651] type=1400 audit(1394177766.465:178): avc: denied { open } for pid=2378 comm="gpg2" path="/tmp/evolution-pgp.7SCJCX" dev="tmpfs" ino=10027 scontext=staff_u:sysadm_r:gpg_t tcontext=system_u:object_r:tmp_t tclass=file
[ 193.766692] type=1400 audit(1394177795.942:179): avc: denied { sigchld } for pid=1 comm="systemd" scontext=staff_u:sysadm_r:sysadm_dbusd_t tcontext=system_u:system_r:kernel_t tclass=process
[ 246.306818] SELinux: unable to change security options during remount (dev tmpfs, type=tmpfs)

I can't help but notice that the output of the remount here is the same
as that during systemd-remount-fs.service failing during boot. Note
also that SELinux is still in permissive mode - I imagine I'd be going
nowhere fast if I tried booting in enforcing mode at this stage. :)


> My system gives the following:
>
> #v+
> $ mount | grep run
> tmpfs on /run type tmpfs (rw,rootcontext=system_u:object_r:var_run_t,seclabel,nosuid,nodev,noexec,relatime)
> #v-

nemesis ~ # mount | grep run
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)

nemesis ~ # grep run /etc/fstab
tmpfs /run tmpfs remount,mode=0755,nosuid,nodev,context=system_u:object_r:var_run_t 0 0

I also tried remounting with only the options you specified
("remount,context=...") instead of the full set, with the same result.

I'm not sure how to get more information out of the SELinux subsystem in
order to get more information out of it...

Cheers;
wraeth

On Fri, 2014-03-07 at 18:56 +1100, wraeth wrote:

Firstly, sorry for double-post before - bad connection and all :-/

> On Thu, 2014-03-06 at 15:15 +0000, Sven Vermeulen wrote:
> > If you do something like the following, does the context then appear?
> >
> > #v+
> > mount -o remount,context=system_u:object_r:var_run_t /run
> > #v-

So I've been slowly plugging away at this trying to figure out why I
can't seem to get my /run filesystem mounted with the correct security
context. Here's what I've tried so far:

manually issue `mount -o remount,context=...`
Fails with "/run not mounted or bad option". From my readings on the
'net, the kernel will actually refuse to remount context-labelled
filesystems. This is also echoed in mount's manpage:
"Note that kernel rejects any remount request that includes the context
option even if unchanged from the current context."

drop into emergency boot shell and remount /run
Same as above, the filesystem refuses to remount.

patch init script for dracut initramfs
I actually thought this could be the best way to resolve the issue. I
was quickly disillusioned. At the time the init script mounts the /run
filesystem, the kernel has yet to initialize SELinux, and according to
mail archive [1] (I see I'm not the first) mount will actually strip
context options from mount commands if it finds that SELinux is not
active. I can't help but agree with this as per the dmesg output:

[ 8.540741] dracut: Mounted root filesystem /dev/mapper/luks-dbfe9b56-8185-4cea-8f52-086bd41382df
[ 8.809942] dracut: Switching root
<snip>
[ 9.420023] SELinux: Completing initialization.
[ 9.420024] SELinux: Setting up existing superblocks.

sysinit service
I even went to the length of creating a service in the sysinit.target
prior to systemd-udevd.service to remount the run filesystem using the
same method that the dracut init script uses - to mount the filesystem
as /newrun, copy everything over, then `mount --move` it. This again
failed, but honestly I'm not surprised at that.

So at this stage I was somewhat frustrated that I hadn't come up with
any solution, so I decided to try looking at a working example to see
where the difference may lie. So I fired up a freshly installed virtual
machine running Fedora 20, got into a terminal and:

[root@asinine ~]# mount | grep run
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)

This looks remarkably familiar...
nemesis ~ # mount | grep run
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)

So now I feel I should ask the obvious question: does the /run
filesystem, being a tmpfs-based filesystem, need to be mounted with
specific security contexts, or is the mount option of 'seclabel'
sufficient?

If 'seclabel' is sufficient, then I don't think I need to do anything
else with regards to filesystem labelling or anything like that - just
the copious avc denials to contend with now! :)

Cheers;
wraeth

[1] http://www.gossamer-threads.com/lists/gentoo/hardened/269150

The seclabel option isn't sufficient unless the /run location has its
labels reset as part of the bootup (akin to "restorecon -R /run" which
might be the case with systems and/or in fedora.

/run *must* have var_run_t as label. The context= mount option is "just" a
way to achieve that.

Wkr,
Sven
On Mar 11, 2014 10:43 AM, "wraeth" <wraeth@privatdemail.net> wrote:

> On Fri, 2014-03-07 at 18:56 +1100, wraeth wrote:
>
> Firstly, sorry for double-post before - bad connection and all :-/
>
> > On Thu, 2014-03-06 at 15:15 +0000, Sven Vermeulen wrote:
> > > If you do something like the following, does the context then appear?
> > >
> > > #v+
> > > mount -o remount,context=system_u:object_r:var_run_t /run
> > > #v-
>
> So I've been slowly plugging away at this trying to figure out why I
> can't seem to get my /run filesystem mounted with the correct security
> context. Here's what I've tried so far:
>
> manually issue `mount -o remount,context=...`
> Fails with "/run not mounted or bad option". From my readings on the
> 'net, the kernel will actually refuse to remount context-labelled
> filesystems. This is also echoed in mount's manpage:
> "Note that kernel rejects any remount request that includes the context
> option even if unchanged from the current context."
>
> drop into emergency boot shell and remount /run
> Same as above, the filesystem refuses to remount.
>
> patch init script for dracut initramfs
> I actually thought this could be the best way to resolve the issue. I
> was quickly disillusioned. At the time the init script mounts the /run
> filesystem, the kernel has yet to initialize SELinux, and according to
> mail archive [1] (I see I'm not the first) mount will actually strip
> context options from mount commands if it finds that SELinux is not
> active. I can't help but agree with this as per the dmesg output:
>
> [ 8.540741] dracut: Mounted root filesystem
> /dev/mapper/luks-dbfe9b56-8185-4cea-8f52-086bd41382df
> [ 8.809942] dracut: Switching root
> <snip>
> [ 9.420023] SELinux: Completing initialization.
> [ 9.420024] SELinux: Setting up existing superblocks.
>
> sysinit service
> I even went to the length of creating a service in the sysinit.target
> prior to systemd-udevd.service to remount the run filesystem using the
> same method that the dracut init script uses - to mount the filesystem
> as /newrun, copy everything over, then `mount --move` it. This again
> failed, but honestly I'm not surprised at that.
>
> So at this stage I was somewhat frustrated that I hadn't come up with
> any solution, so I decided to try looking at a working example to see
> where the difference may lie. So I fired up a freshly installed virtual
> machine running Fedora 20, got into a terminal and:
>
> [root@asinine ~]# mount | grep run
> tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)
>
> This looks remarkably familiar...
> nemesis ~ # mount | grep run
> tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)
>
> So now I feel I should ask the obvious question: does the /run
> filesystem, being a tmpfs-based filesystem, need to be mounted with
> specific security contexts, or is the mount option of 'seclabel'
> sufficient?
>
> If 'seclabel' is sufficient, then I don't think I need to do anything
> else with regards to filesystem labelling or anything like that - just
> the copious avc denials to contend with now! :)
>
> Cheers;
> wraeth
>
> [1] http://www.gossamer-threads.com/lists/gentoo/hardened/269150
>