Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Hardened

Booting selinux on the bleeding edge

 

 

Gentoo hardened RSS feed   Index | Next | Previous | View Threaded


pauldv at gentoo

Apr 4, 2012, 4:12 AM

Post #1 of 6 (486 views)
Permalink
Booting selinux on the bleeding edge

I decided to finally take the plunge and try to see if I could get selinux
on my machine. There were some easy problems to fix (like selinux-cups not
depending on selinux-lpd) but it seems that latest openrc with latest udev
and latest kernel don't really like eachother. I get quite some errors at
boot as well as misslabeled dynamic files (/run and /dev are misslabeled).
I've attached the errors and the output of relabeling /dev

Paul

--
Paul de Vrieze
Developer
Mail: pauldv [at] gentoo
Homepage: http://www.devrieze.net
Attachments: relabeldev (4.12 KB)
  selinux-boot.log (8.58 KB)


swift at gentoo

Apr 5, 2012, 8:52 AM

Post #2 of 6 (464 views)
Permalink
Re: Booting selinux on the bleeding edge [In reply to]

On Wed, Apr 04, 2012 at 12:12:35PM +0100, Paul de Vrieze wrote:
> I decided to finally take the plunge and try to see if I could get selinux
> on my machine. There were some easy problems to fix (like selinux-cups not
> depending on selinux-lpd) but it seems that latest openrc with latest udev
> and latest kernel don't really like eachother. I get quite some errors at
> boot as well as misslabeled dynamic files (/run and /dev are misslabeled).
> I've attached the errors and the output of relabeling /dev

As I see kdevtmpfs in the logs, I assume you have CONFIG_DEVTMPFS set?
I know it wasn't supported a while ago, because the kernel isn't
SELinux-aware (in the sense that it calls libselinux to set file contexts
and such). There was some talk about udev detecting the creates and
(re)setting the contexts through udev, but that caused issued with libvirt.

I'm not sure about the current state about it though...

Wkr,
Sven Vermeulen


pauldv at gentoo

Apr 6, 2012, 2:20 PM

Post #3 of 6 (466 views)
Permalink
Re: Booting selinux on the bleeding edge [In reply to]

On 5 April 2012 16:52, Sven Vermeulen <swift [at] gentoo> wrote:

> On Wed, Apr 04, 2012 at 12:12:35PM +0100, Paul de Vrieze wrote:
> > I decided to finally take the plunge and try to see if I could get
> selinux
> > on my machine. There were some easy problems to fix (like selinux-cups
> not
> > depending on selinux-lpd) but it seems that latest openrc with latest
> udev
> > and latest kernel don't really like eachother. I get quite some errors at
> > boot as well as misslabeled dynamic files (/run and /dev are
> misslabeled).
> > I've attached the errors and the output of relabeling /dev
>
> As I see kdevtmpfs in the logs, I assume you have CONFIG_DEVTMPFS set?
> I know it wasn't supported a while ago, because the kernel isn't
> SELinux-aware (in the sense that it calls libselinux to set file contexts
> and such). There was some talk about udev detecting the creates and
> (re)setting the contexts through udev, but that caused issued with libvirt.
>
> I'm not sure about the current state about it though..
>

Yeah, I have DEVTMPFS set as latest openrc (which is needed by latest udev
or the other way around) demands it (it will fail horribly without it
(been there, fixed it, got the t-shirt)).

Paul

--
Paul de Vrieze
Developer
Mail: pauldv [at] gentoo
Homepage: http://www.devrieze.net


swift at gentoo

Apr 7, 2012, 12:38 AM

Post #4 of 6 (462 views)
Permalink
Re: Booting selinux on the bleeding edge [In reply to]

On Fri, Apr 06, 2012 at 10:20:37PM +0100, Paul de Vrieze wrote:
> Yeah, I have DEVTMPFS set as latest openrc (which is needed by latest udev
> or the other way around) demands it (it will fail horribly without it
> (been there, fixed it, got the t-shirt)).

Oh ffs...

*sigh*

devfs all over again.

Sven

PS Yeah, I have not been running an ~arch system in the last few months as
the new policies were in need of shaping even for stable systems. I hope to
get some time free again to try out an ~arch system.


swift at gentoo

Apr 8, 2012, 4:44 AM

Post #5 of 6 (455 views)
Permalink
Re: Booting selinux on the bleeding edge [In reply to]

On Wed, Apr 04, 2012 at 12:12:35PM +0100, Paul de Vrieze wrote:
> I decided to finally take the plunge and try to see if I could get selinux
> on my machine. There were some easy problems to fix (like selinux-cups not
> depending on selinux-lpd) but it seems that latest openrc with latest udev
> and latest kernel don't really like eachother. I get quite some errors at
> boot as well as misslabeled dynamic files (/run and /dev are misslabeled).
> I've attached the errors and the output of relabeling /dev

Hmm, I can't seem to reproduce all you see, although I can see it is
becoming quite messy nowadays. Is the /run mislabeling still a fact? What
might be happening (although I can't confirm this here) is that your
(unmounted) /run has no good label. The moment openrc mounts it (through
/lib64/rc/sh/init.sh) the mount inherits the context, but it also means that
if you relabel, you are only relabeling the tmpfs (and not the real
directory).

You can "solve" it by bindmounting your root file system, and then setting
the context of /run (chcon -t var_run_t should suffice).

The /dev is another issue. I currently don't have to deal with it as I'm
forced to use an initramfs (as I have a separate /usr) so I need to relabel
/dev anyhow before switching to enforcing mode :-( But I can imagine what
happens... kdevtmpfs runs as kernel_t and creates device files in /dev
(which are labeled device_t).

From what I read, udev is supposed to relabel the files. Although I can't
confirm this, I also see that udev isn't the first thing that is started
(and that, if it gets started in enforcing mode, it might already need a
correctly labeled /dev when running without unconfined domains).

Oh well, still lots of work ahead.

Wkr,
Sven Vermeulen


pauldv at gentoo

Apr 8, 2012, 1:06 PM

Post #6 of 6 (457 views)
Permalink
Re: Booting selinux on the bleeding edge [In reply to]

On 8 April 2012 12:44, Sven Vermeulen <swift [at] gentoo> wrote:

> Hmm, I can't seem to reproduce all you see, although I can see it is
> becoming quite messy nowadays. Is the /run mislabeling still a fact? What
> might be happening (although I can't confirm this here) is that your
> (unmounted) /run has no good label. The moment openrc mounts it (through
> /lib64/rc/sh/init.sh) the mount inherits the context, but it also means
> that
> if you relabel, you are only relabeling the tmpfs (and not the real
> directory).
>
> The label of the /run directory was wrong. I'll check later whether that
has fixed it (I don't really want to reboot now for that). It's strange as
I did the same trick with /proc, /sys etc. (copying whatever was set
through restorecon). The context was "system_u:var_run_t:file_t"



> You can "solve" it by bindmounting your root file system, and then setting
> the context of /run (chcon -t var_run_t should suffice).
>
> The /dev is another issue. I currently don't have to deal with it as I'm
> forced to use an initramfs (as I have a separate /usr) so I need to relabel
> /dev anyhow before switching to enforcing mode :-( But I can imagine what
> happens... kdevtmpfs runs as kernel_t and creates device files in /dev
> (which are labeled device_t).
>

My system uses an initrd as well (as it has an lvm based root filesystem).


>
> From what I read, udev is supposed to relabel the files. Although I can't
> confirm this, I also see that udev isn't the first thing that is started
> (and that, if it gets started in enforcing mode, it might already need a
> correctly labeled /dev when running without unconfined domains).


If you have some info that I could look at I'd like to help. I'm fairly new
at selinux and I still find it rather complex, but what better way to learn
it than to get your hands dirty ;-). Btw. This is a desktop system which
might provide its own interesting challenges.

Paul

--
Paul de Vrieze
Developer
Mail: pauldv [at] gentoo
Homepage: http://www.devrieze.net

Gentoo hardened RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.