denials with filesystem associate

denials with filesystem associate

[Michal Svoboda]

[-- Attachment #1: Type: text/plain, Size: 2020 bytes --]

Hello,

see log below... what could be causing these denials? And, what
operations exactly are those?

With regards,
Michal Svoboda

[    0.000000] Linux version 2.6.32-trunk-amd64 (Debian 2.6.32-5)
(ben@decadent.org.uk) (gcc version 4.3.4 (Debian 4.3.4-6) ) #1 SMP Sun
Jan 10 22:40:40 UTC 2010
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-2.6.32-trunk-amd64
root=UUID=6f30ce45-1f28-4abb-9271-aa56e2af839d ro selinux=1

...

[    2.840057] usb 1-2: new full speed USB device using uhci_hcd and
address 2
[    3.159070] udev: starting version 151
[    3.191497] usb 1-2: New USB device found, idVendor=0627,
idProduct=0001
[    3.192862] usb 1-2: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[    3.193672] usb 1-2: Product: QEMU USB Tablet
[    3.194362] usb 1-2: Manufacturer: QEMU 0.11.1
[    3.195071] usb 1-2: SerialNumber: 1
[    3.200148] type=1400 audit(1267376854.206:4): avc:  denied  {
associate } for  pid=219 comm="khubd" name="002"
scontext=system_u:object_r:unlabeled_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem
[    3.202848] usb 1-2: configuration #1 chosen from 1 choice
[    3.403509] type=1400 audit(1267376854.406:5): avc:  denied  {
associate } for  pid=383 comm="modprobe" name="event0"
scontext=system_u:object_r:unlabeled_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem
[    3.413673] input: PC Speaker as
/devices/platform/pcspkr/input/input3
[    3.422709] processor LNXCPU:00: registered as cooling_device0
[    3.440793] piix4_smbus 0000:00:01.3: SMBus Host Controller at
0xb100, revision 0
[    3.442750] type=1400 audit(1267376854.446:6): avc:  denied  {
associate } for  pid=383 comm="modprobe" name="event1"
scontext=system_u:object_r:unlabeled_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem
[    3.503568] type=1400 audit(1267376854.506:9): avc:  denied  {
associate } for  pid=383 comm="modprobe" name="event2"
scontext=system_u:object_r:unlabeled_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: denials with filesystem associate

[Stephen Smalley]

On Sun, 2010-02-28 at 23:38 +0100, Michal Svoboda wrote:
> Hello,
> 
> see log below... what could be causing these denials? And, what
> operations exactly are those?

On file creation, there is an associate check between the security
context of the file and the security context of the containing
filesystem.  In your particular case though the real issue is that you
have an unlabeled filesystem type that needs a genfscon or fs_use rule
added to your policy.   Look for a log message that says something along
the lines of:
SELinux:  initialized (dev ..., type ...), not configured for labeling

You might need to enable kern.debug logging in your syslog
configuration.

> 
> With regards,
> Michal Svoboda
> 
> [    0.000000] Linux version 2.6.32-trunk-amd64 (Debian 2.6.32-5)
> (ben@decadent.org.uk) (gcc version 4.3.4 (Debian 4.3.4-6) ) #1 SMP Sun
> Jan 10 22:40:40 UTC 2010
> [    0.000000] Command line: BOOT_IMAGE=/vmlinuz-2.6.32-trunk-amd64
> root=UUID=6f30ce45-1f28-4abb-9271-aa56e2af839d ro selinux=1
> 
> ...
> 
> [    2.840057] usb 1-2: new full speed USB device using uhci_hcd and
> address 2
> [    3.159070] udev: starting version 151
> [    3.191497] usb 1-2: New USB device found, idVendor=0627,
> idProduct=0001
> [    3.192862] usb 1-2: New USB device strings: Mfr=3, Product=2,
> SerialNumber=1
> [    3.193672] usb 1-2: Product: QEMU USB Tablet
> [    3.194362] usb 1-2: Manufacturer: QEMU 0.11.1
> [    3.195071] usb 1-2: SerialNumber: 1
> [    3.200148] type=1400 audit(1267376854.206:4): avc:  denied  {
> associate } for  pid=219 comm="khubd" name="002"
> scontext=system_u:object_r:unlabeled_t:s0
> tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem
> [    3.202848] usb 1-2: configuration #1 chosen from 1 choice
> [    3.403509] type=1400 audit(1267376854.406:5): avc:  denied  {
> associate } for  pid=383 comm="modprobe" name="event0"
> scontext=system_u:object_r:unlabeled_t:s0
> tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem
> [    3.413673] input: PC Speaker as
> /devices/platform/pcspkr/input/input3
> [    3.422709] processor LNXCPU:00: registered as cooling_device0
> [    3.440793] piix4_smbus 0000:00:01.3: SMBus Host Controller at
> 0xb100, revision 0
> [    3.442750] type=1400 audit(1267376854.446:6): avc:  denied  {
> associate } for  pid=383 comm="modprobe" name="event1"
> scontext=system_u:object_r:unlabeled_t:s0
> tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem
> [    3.503568] type=1400 audit(1267376854.506:9): avc:  denied  {
> associate } for  pid=383 comm="modprobe" name="event2"
> scontext=system_u:object_r:unlabeled_t:s0
> tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem
> 
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: denials with filesystem associate

[Michal Svoboda]

[-- Attachment #1: Type: text/plain, Size: 850 bytes --]

Stephen Smalley wrote:
> On file creation, there is an associate check between the security
> context of the file and the security context of the containing
> filesystem.  

Is there anything I could read up to understand this mechanism?

> In your particular case though the real issue is that you
> have an unlabeled filesystem type that needs a genfscon or fs_use rule
> added to your policy.   Look for a log message that says something along
> the lines of:
> SELinux:  initialized (dev ..., type ...), not configured for labeling

[    2.780406] SELinux: initialized (dev devtmpfs, type devtmpfs), not
configured for labeling

I think this is the new kernel-make dev filesystem that appears in .32
or so. So I need to recompile the base module to use transition SIDs,
like on normal tmpfs, right?

Regards,
Michal Svoboda

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: denials with filesystem associate

[Stephen Smalley]

On Mon, 2010-03-01 at 17:56 +0100, Michal Svoboda wrote:
> Stephen Smalley wrote:
> > On file creation, there is an associate check between the security
> > context of the file and the security context of the containing
> > filesystem.  
> 
> Is there anything I could read up to understand this mechanism?

The particular permission checks for operations were described in:
http://www.nsa.gov/research/_files/selinux/papers/slinux-abs.shtml
and
http://www.nsa.gov/research/_files/selinux/papers/module-abs.shtml

There is also a wiki page with information on classes and permissions,
http://www.selinuxproject.org/page/ObjectClassesPerms

> > In your particular case though the real issue is that you
> > have an unlabeled filesystem type that needs a genfscon or fs_use rule
> > added to your policy.   Look for a log message that says something along
> > the lines of:
> > SELinux:  initialized (dev ..., type ...), not configured for labeling
> 
> [    2.780406] SELinux: initialized (dev devtmpfs, type devtmpfs), not
> configured for labeling
> 
> I think this is the new kernel-make dev filesystem that appears in .32
> or so. So I need to recompile the base module to use transition SIDs,
> like on normal tmpfs, right?

Yes.  Looks like Fedora policy has:
fs_use_trans devtmpfs gen_context(system_u:object_r:tmpfs_t,s0);

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: denials with filesystem associate

[Michal Svoboda]

[-- Attachment #1: Type: text/plain, Size: 561 bytes --]

Stephen Smalley wrote:
> On file creation, there is an associate check between the security
> context of the file and the security context of the containing
> filesystem.  

OK, I think I now understand this permission. But it seems that in a
normal (reference) policy all files are permitted on all filesystems.
Are there cases when they're not?

And secondly, it seems that every file type has an associate permission
on itself, ie.

   allow etc_runtime_t etc_runtime_t : filesystem associate ; 

Why is this so?

Regards,
Michal Svoboda


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: denials with filesystem associate

[Stephen Smalley]

On Tue, 2010-03-02 at 12:12 +0100, Michal Svoboda wrote:
> Stephen Smalley wrote:
> > On file creation, there is an associate check between the security
> > context of the file and the security context of the containing
> > filesystem.  
> 
> OK, I think I now understand this permission. But it seems that in a
> normal (reference) policy all files are permitted on all filesystems.
> Are there cases when they're not?

I think the refpolicy allows most associations, although it wouldn't
need to allow types that should only appear on filesystems that support
per-file security labeling to appear on filesystems that do not support
security labeling.  The original concept was that we might bind specific
types and/or specific levels to specific filesystems.  But that requires
a custom configuration for a particular system.  Note that in the
original SELinux implementation, we had a way to store the filesystem
security context in the filesystem (as part of the persistent label
mapping), before we transitioned to using xattrs.  Today the only way to
assign a particular filesystem security context to a particular
filesystem is to use the fscontext= mount option; otherwise you'll just
get the default for that filesystem type from the policy.

> And secondly, it seems that every file type has an associate permission
> on itself, ie.
> 
>    allow etc_runtime_t etc_runtime_t : filesystem associate ; 
> 
> Why is this so?

Likely to allow all possible cases of context= mounts up front.

FWIW, SELinux-specific mount options include:
1) context= Assign the specified security context to the filesystem and
all files within it, ignoring xattrs even if they are present/supported.
2) fscontext= Assign the specified security context to the filesystem
rather than the policy-defined default for that filesystem type; does
not affect the mechanism for determining the context of files within the
filesystem.
3) defcontext= Assign the specified security context to files in the
filesystem that lack an xattr value rather than the policy-defined
default.
4) rootcontext= Assign the specified security context to the root
directory of the filesystem.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

System console hangs on boot in enforced unless some permissions added (with 2.6.32-3).

[selinux]

On Mon, Mar 01, 2010 at 12:09:16PM -0500, Stephen Smalley wrote:
> On Mon, 2010-03-01 at 17:56 +0100, Michal Svoboda wrote:
> > Stephen Smalley wrote:
> > > On file creation, there is an associate check between the security
> > > context of the file and the security context of the containing
> > > filesystem.  
> > 
> > Is there anything I could read up to understand this mechanism?
> 
> The particular permission checks for operations were described in:
> http://www.nsa.gov/research/_files/selinux/papers/slinux-abs.shtml
> and
> http://www.nsa.gov/research/_files/selinux/papers/module-abs.shtml
> 
> There is also a wiki page with information on classes and permissions,
> http://www.selinuxproject.org/page/ObjectClassesPerms
> 
> > > In your particular case though the real issue is that you
> > > have an unlabeled filesystem type that needs a genfscon or fs_use rule
> > > added to your policy.   Look for a log message that says something along
> > > the lines of:
> > > SELinux:  initialized (dev ..., type ...), not configured for labeling
> > 
> > [    2.780406] SELinux: initialized (dev devtmpfs, type devtmpfs), not
> > configured for labeling
> > 
> > I think this is the new kernel-make dev filesystem that appears in .32
> > or so. So I need to recompile the base module to use transition SIDs,
> > like on normal tmpfs, right?
> 
> Yes.  Looks like Fedora policy has:
> fs_use_trans devtmpfs gen_context(system_u:object_r:tmpfs_t,s0);
Heh, and now the Debian/testing selinux-policy-default have the same.

But.
Is it only me unable to run Debian's 2.6.32-3 kernel with SELinux in enforced mode,
or is anyone else's system blocked by the devtmpfs compiled into the kernel? :)

Look, I have these strange messages in permissive mode:
	type=AVC msg=audit(1272355319.117:102): avc:  denied  { search } for  pid=1668 comm="getty" name="/" dev=devtmpfs ino=4 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
	type=AVC msg=audit(1272355319.117:102): avc:  denied  { write } for  pid=1668 comm="getty" name="/" dev=devtmpfs ino=4 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
	type=AVC msg=audit(1272355319.117:102): avc:  denied  { add_name } for  pid=1668 comm="getty" name="vcs2" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
	type=AVC msg=audit(1272355319.117:102): avc:  denied  { create } for  pid=1668 comm="getty" name="vcs2" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file
and I have a totally freezed console (while network services running, for ex. ssh),
unable to switch VTs and scroll them, not even numlock is switching.
And I know that getty does not run in kernel_t and never supposed to mknod anything.
And if I boot in single-user, that boots okay, but if I ever try to "echo > /dev/tty2",
I immediately have my console freezed in the same manner when in enforced mode,
but get the same AVCs in permissive, but with comm="bash", but hey, bash does not have
the code for creating a special file "vcs2", doesn't it?

Note in the AVCs: dev=devtmpfs, but I have no one in /proc/mounts,
also ino=4, but I scanned all filesystems (while in single-user mode,
just after receiving these messages), there is no inode=4 with tmpfs_t type.
So it was very hard to figure out, what is happening, I am not quite a
current kernel expert.

So, is it true, that someone (in debian?) turned the devtmpfs on in 2.6.32-3 and now
that filesystem exists even when not mounted, and even worse, it's operations
are executed on behalf of current process, but within the kernel_t domain?
And kernel_t should not create device nodes in tmpfs_t directories, right?
And finally, all that together just breaks the system bootup process in an
almost untraceable manner?

It seems, that being denied to search tmpfs_t and create nodes there,
the kernel just loses some locks locked (I believe), but then it looks like a kernel bug,
not a SELinux fault.

But, as you may guess, adding the rules
  allow kernel_t { tmpfs_t device_node }:{ chr_file blk_file lnk_file } create;
  allow kernel_t tmpfs_t:dir { search write add_name create };
allows the system to boot just fine. But is it a proper solution?

So, after all, now with my "fix" just everyone with mount privilege can do
 # mount -t devtmpfs blablabla-no-device-is-needed /mountpoint
to get directory full of device nodes with NO proper labelling?
Sometime in the past I had set up environments with "limited root"
so now I am concerned about that, there were mount privileges
(for /dev/pts and /proc as I recall).

Well, I'm afraid, that I am misunderstanding the situation,
so things are not so bad (but hey, it took me 3 days to make the system bootable),
so please, respond, anyone who have tried debian's 2.6.32-3 kernel
with selinux-policy-default/testing. I do personally use debian/testing
with selinux-policy-default 2:0.2.20091117-2.
Please, suggest any your solution or suggestion or just experience (positive or negative).

And does anyone have any suggestions for proper further reaction?
(I believe, that all caused by a bad code design quality or somewhat like that,
but perhaps some of you may argue pro or contra.)

Thanks for your time.

-- 
Alexey S.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: System console hangs on boot in enforced unless some permissions added (with 2.6.32-3).

[Stephen Smalley]

On Wed, 2010-04-28 at 20:04 +0400, selinux@udmvt.ru wrote:
> Is it only me unable to run Debian's 2.6.32-3 kernel with SELinux in enforced mode,
> or is anyone else's system blocked by the devtmpfs compiled into the kernel? :)
> 
> Look, I have these strange messages in permissive mode:
> 	type=AVC msg=audit(1272355319.117:102): avc:  denied  { search } for  pid=1668 comm="getty" name="/" dev=devtmpfs ino=4 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
> 	type=AVC msg=audit(1272355319.117:102): avc:  denied  { write } for  pid=1668 comm="getty" name="/" dev=devtmpfs ino=4 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
> 	type=AVC msg=audit(1272355319.117:102): avc:  denied  { add_name } for  pid=1668 comm="getty" name="vcs2" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
> 	type=AVC msg=audit(1272355319.117:102): avc:  denied  { create } for  pid=1668 comm="getty" name="vcs2" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file

Two problems:
- getty shouldn't be in kernel_t.  This means that you never
transitioned out of kernel_t to init_t upon executing /sbin/init.
Is /sbin/init labeled correctly?

- Your devtmpfs instance apparently wasn't labeled.  In Fedora, there is
a restorecon -R /dev that happens from rc.sysinit to fix up labels once
policy has loaded.

You might have fewer errors too if you use device_t rather than tmpfs_t
as the default in your fs_use_trans statement.

> So, after all, now with my "fix" just everyone with mount privilege can do
>  # mount -t devtmpfs blablabla-no-device-is-needed /mountpoint
> to get directory full of device nodes with NO proper labelling?

Once it has been initially mounted and labeled, all subsequent mounts
should get the same instance - they don't create a new one each time.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: System console hangs on boot in enforced unless some permissions added (with 2.6.32-3).

[selinux]

On Wed, Apr 28, 2010 at 03:32:37PM -0400, Stephen Smalley wrote:
> On Wed, 2010-04-28 at 20:04 +0400, selinux@udmvt.ru wrote:
> > Is it only me unable to run Debian's 2.6.32-3 kernel with SELinux in enforced mode,
> > or is anyone else's system blocked by the devtmpfs compiled into the kernel? :)
> > 
> > Look, I have these strange messages in permissive mode:
> > 	type=AVC msg=audit(1272355319.117:102): avc:  denied  { search } for  pid=1668 comm="getty" name="/" dev=devtmpfs ino=4 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
> > 	type=AVC msg=audit(1272355319.117:102): avc:  denied  { write } for  pid=1668 comm="getty" name="/" dev=devtmpfs ino=4 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
> > 	type=AVC msg=audit(1272355319.117:102): avc:  denied  { add_name } for  pid=1668 comm="getty" name="vcs2" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
> > 	type=AVC msg=audit(1272355319.117:102): avc:  denied  { create } for  pid=1668 comm="getty" name="vcs2" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file
> 
> Two problems:
> - getty shouldn't be in kernel_t.  This means that you never
> transitioned out of kernel_t to init_t upon executing /sbin/init.
> Is /sbin/init labeled correctly?
Yes, ofcourse, it is labelled. Plus, my little "fix" by allowing kernel_t
access to tmpfs_t allowed the system to properly boot and function in
enforced mode and transition to system services and to getty_t, etc, etc.
Can that happen with labelling problems?
And ofcourse, getty should never be in kernel_t.

> 
> - Your devtmpfs instance apparently wasn't labeled.  
Yes, ofcourse!
> In Fedora, there is
> a restorecon -R /dev that happens from rc.sysinit to fix up labels once
> policy has loaded.
Debian/testing uses sysfs+udev with tmpfs for storing /dev, not devtmpfs.
Not I nor bootscripts do mount devtmpfs ANYWHERE in the system, so relabelling
is not possible until devtmpfs is mounted, but I do not need it mounted. But it
generates avc denials while unmounted too, this is a rather ghosty behavior.
And that is not only avc messages, that denials break the system.

Hehe. I knew that somebody will respond in this manner. It was my first reaction too.
But here is what I have figured out:
  - my devtmpfs is NOT MOUNTED anywhere (and was not even in initramfs), so getty should
    not and cannot get access to it
  - there is no code in getty to create chr_file files, really
  - my getty is really running under getty_t
  - if I run in single user mode (before gettys), and try to access unused virtual console
    (by opening /dev/tty2 for example) I get the same AVCs, but with another command in comm="",
    so if I do echo > /dev/tty2, I get comm="bash", if I do 'openvt -c 3', I get comm="openvt",
    and, ofcourse, id -Z does not show any kernel_t, really, there is sysadm_t.
  - if I load modules (that register device special files) after SELinux is initialized, I get
    kernel BUG messages and that drivers unusable and unloadable, so now, all modules, that
    I may need in future, is loaded in initramfs.
  - this all does not happen with selinux=0 kernel boot parameter.

> 
> You might have fewer errors too if you use device_t rather than tmpfs_t
> as the default in your fs_use_trans statement.
  - I do not use any at all. I do not need devtmpfs either. Is it defined in policy?
So, is it a policy bug?
Anyway, is kernel_t allowed to create files in device_t directories ? No difference with tmpfs_t.

> 
> > So, after all, now with my "fix" just everyone with mount privilege can do
> >  # mount -t devtmpfs blablabla-no-device-is-needed /mountpoint
> > to get directory full of device nodes with NO proper labelling?
> 
> Once it has been initially mounted and labeled, all subsequent mounts
> should get the same instance - they don't create a new one each time.

But new devices are created there dynamically, and they are not labelled!
Should I start a cron job every minute, that will mount devtmpfs, relabel it, and then unmount?
Ofcourse not! What is the option then?

And I have googled on the subject and have found strong opposition of some kernel
maintainers to the appearance of devtmpfs in the mainline existed in the past.
And you had your own point on that, here is the citation from Alan Cox and Greg KH writing each other:
Alan Cox:
 Also can you confirm the SELinux issues raised by Stephen Smalley and
 David Quigley were fixed and resolved.

Greg KH (proposing new new patch):
 From what I recall, yes, they were.  I'm guessing the Red Hat boot tests
 performed by Harald confirms this.
END CITATION (from http://lkml.org/lkml/2009/8/5/357)

I do not personally know who is Harald and whether I can trust he is really performed
boot tests on Red Hat with SELinux enforced, but I think, that my boot test found the opposite.
Perhaps, you, Stephen Smalley, have raised some other issues then and now I have met my own. :(
But I am still interested to figure out, is it only me having these issues, or
devtmpfs patch activated really brings down SELinux enabled systems (without the policy patched)?

> 
> -- 
> Stephen Smalley
> National Security Agency
And thank you for you discussing this.

-- 
Alexey S.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: System console hangs on boot in enforced unless some permissions added (with 2.6.32-3).

[Stephen Smalley]

On Thu, 2010-04-29 at 10:14 +0400, selinux@udmvt.ru wrote:
> Yes, ofcourse, it is labelled. Plus, my little "fix" by allowing kernel_t
> access to tmpfs_t allowed the system to properly boot and function in
> enforced mode and transition to system services and to getty_t, etc, etc.
> Can that happen with labelling problems?
> And ofcourse, getty should never be in kernel_t.

Ok, I understand your problem now.
devtmpfs internally switches to the initial task's credentials when
performing internal operations like creating new device nodes when they
are requested by the driver.  Otherwise we'd have to allow whatever
happened to be the currently running process (e.g. getty_t) to perform
those operations, whereas they aren't originating from that process at
all and we don't want to permit the process to perform that action on
its own.  That's why it shows up as kernel_t.  In the Fedora default
targeted policy, kernel_t is unconfined and everything just works.  If
we don't already have explicit allow rules permitting kernel_t to create
these nodes in whatever default type we assign to devtmpfs, then that's
a policy bug.

> Debian/testing uses sysfs+udev with tmpfs for storing /dev, not devtmpfs.
> Not I nor bootscripts do mount devtmpfs ANYWHERE in the system, so relabelling
> is not possible until devtmpfs is mounted, but I do not need it mounted. But it
> generates avc denials while unmounted too, this is a rather ghosty behavior.
> And that is not only avc messages, that denials break the system.

On Fedora, I see:
$ grep devtmpfs /proc/mounts
/proc/mounts:udev /dev devtmpfs rw,seclabel,relatime,size=1016584k,nr_inodes=254146,mode=755 0 0

Depending on your kernel config, the devtmpfs kernel code will
automatically mount the devtmpfs instance on /dev, without any action on
your part.  You can explicit control this action by specifying
devtmpfs.mount=1 or devtmpfs.mount=0 on the kernel command line.  In
Fedora, the mounting defaults to enabled.  It sounds like the reverse is
true in Debian.

> Hehe. I knew that somebody will respond in this manner. It was my first reaction too.
> But here is what I have figured out:
>   - my devtmpfs is NOT MOUNTED anywhere (and was not even in initramfs), so getty should
>     not and cannot get access to it

So I guess CONFIG_DEVTMPFS_MOUNT=n in your config.

>   - there is no code in getty to create chr_file files, really
>   - my getty is really running under getty_t

Right, this is an internal operation within the kernel; whenever a
driver requests a device node, devtmpfs automatically creates the node.
devtmpfs switches credentials around this internal operation so that we
do not need to authorize getty or other userspace processes for this
operation.

> > You might have fewer errors too if you use device_t rather than tmpfs_t
> > as the default in your fs_use_trans statement.
>   - I do not use any at all. I do not need devtmpfs either. Is it defined in policy?
> So, is it a policy bug?
> Anyway, is kernel_t allowed to create files in device_t directories ? No difference with tmpfs_t.

Looking at refpolicy list archives I see that they tried switching from
tmpfs_t to device_t as the default type for devtmpfs but ran into some
other issues and backed off from it for now.  So it is presently still
defined as tmpfs_t there.

> > 
> > > So, after all, now with my "fix" just everyone with mount privilege can do
> > >  # mount -t devtmpfs blablabla-no-device-is-needed /mountpoint
> > > to get directory full of device nodes with NO proper labelling?
> > 
> > Once it has been initially mounted and labeled, all subsequent mounts
> > should get the same instance - they don't create a new one each time.
> 
> But new devices are created there dynamically, and they are not labelled!
> Should I start a cron job every minute, that will mount devtmpfs, relabel it, and then unmount?
> Ofcourse not! What is the option then?

If it is mounted on /dev as expected, then the initial restorecon
-R /dev will fix it up on boot and udev should handle labeling any
subsequently created nodes just as before devtmpfs.

> And I have googled on the subject and have found strong opposition of some kernel
> maintainers to the appearance of devtmpfs in the mainline existed in the past.
> And you had your own point on that, here is the citation from Alan Cox and Greg KH writing each other:
> Alan Cox:
>  Also can you confirm the SELinux issues raised by Stephen Smalley and
>  David Quigley were fixed and resolved.
> 
> Greg KH (proposing new new patch):
>  From what I recall, yes, they were.  I'm guessing the Red Hat boot tests
>  performed by Harald confirms this.
> END CITATION (from http://lkml.org/lkml/2009/8/5/357)
> 
> I do not personally know who is Harald and whether I can trust he is really performed
> boot tests on Red Hat with SELinux enforced, but I think, that my boot test found the opposite.
> Perhaps, you, Stephen Smalley, have raised some other issues then and now I have met my own. :(
> But I am still interested to figure out, is it only me having these issues, or
> devtmpfs patch activated really brings down SELinux enabled systems (without the policy patched)?

It seems that there are a couple of problems:
- your kernel has CONFIG_DEVTMPFS=y but CONFIG_DEVTMPFS_MOUNT=n, so you
get to incur the 
- your policy doesn't allow kernel_t unfettered access to the default
type associated with devtmpfs.  That's a policy issue.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] System console hangs on boot in enforced unless some permissions added (with 2.6.32-3).

[Stephen Smalley]

On Thu, 2010-04-29 at 10:14 +0400, selinux at udmvt.ru wrote:
> Yes, ofcourse, it is labelled. Plus, my little "fix" by allowing kernel_t
> access to tmpfs_t allowed the system to properly boot and function in
> enforced mode and transition to system services and to getty_t, etc, etc.
> Can that happen with labelling problems?
> And ofcourse, getty should never be in kernel_t.

Ok, I understand your problem now.
devtmpfs internally switches to the initial task's credentials when
performing internal operations like creating new device nodes when they
are requested by the driver.  Otherwise we'd have to allow whatever
happened to be the currently running process (e.g. getty_t) to perform
those operations, whereas they aren't originating from that process at
all and we don't want to permit the process to perform that action on
its own.  That's why it shows up as kernel_t.  In the Fedora default
targeted policy, kernel_t is unconfined and everything just works.  If
we don't already have explicit allow rules permitting kernel_t to create
these nodes in whatever default type we assign to devtmpfs, then that's
a policy bug.

> Debian/testing uses sysfs+udev with tmpfs for storing /dev, not devtmpfs.
> Not I nor bootscripts do mount devtmpfs ANYWHERE in the system, so relabelling
> is not possible until devtmpfs is mounted, but I do not need it mounted. But it
> generates avc denials while unmounted too, this is a rather ghosty behavior.
> And that is not only avc messages, that denials break the system.

On Fedora, I see:
$ grep devtmpfs /proc/mounts
/proc/mounts:udev /dev devtmpfs rw,seclabel,relatime,size=1016584k,nr_inodes=254146,mode=755 0 0

Depending on your kernel config, the devtmpfs kernel code will
automatically mount the devtmpfs instance on /dev, without any action on
your part.  You can explicit control this action by specifying
devtmpfs.mount=1 or devtmpfs.mount=0 on the kernel command line.  In
Fedora, the mounting defaults to enabled.  It sounds like the reverse is
true in Debian.

> Hehe. I knew that somebody will respond in this manner. It was my first reaction too.
> But here is what I have figured out:
>   - my devtmpfs is NOT MOUNTED anywhere (and was not even in initramfs), so getty should
>     not and cannot get access to it

So I guess CONFIG_DEVTMPFS_MOUNT=n in your config.

>   - there is no code in getty to create chr_file files, really
>   - my getty is really running under getty_t

Right, this is an internal operation within the kernel; whenever a
driver requests a device node, devtmpfs automatically creates the node.
devtmpfs switches credentials around this internal operation so that we
do not need to authorize getty or other userspace processes for this
operation.

> > You might have fewer errors too if you use device_t rather than tmpfs_t
> > as the default in your fs_use_trans statement.
>   - I do not use any at all. I do not need devtmpfs either. Is it defined in policy?
> So, is it a policy bug?
> Anyway, is kernel_t allowed to create files in device_t directories ? No difference with tmpfs_t.

Looking at refpolicy list archives I see that they tried switching from
tmpfs_t to device_t as the default type for devtmpfs but ran into some
other issues and backed off from it for now.  So it is presently still
defined as tmpfs_t there.

> > 
> > > So, after all, now with my "fix" just everyone with mount privilege can do
> > >  # mount -t devtmpfs blablabla-no-device-is-needed /mountpoint
> > > to get directory full of device nodes with NO proper labelling?
> > 
> > Once it has been initially mounted and labeled, all subsequent mounts
> > should get the same instance - they don't create a new one each time.
> 
> But new devices are created there dynamically, and they are not labelled!
> Should I start a cron job every minute, that will mount devtmpfs, relabel it, and then unmount?
> Ofcourse not! What is the option then?

If it is mounted on /dev as expected, then the initial restorecon
-R /dev will fix it up on boot and udev should handle labeling any
subsequently created nodes just as before devtmpfs.

> And I have googled on the subject and have found strong opposition of some kernel
> maintainers to the appearance of devtmpfs in the mainline existed in the past.
> And you had your own point on that, here is the citation from Alan Cox and Greg KH writing each other:
> Alan Cox:
>  Also can you confirm the SELinux issues raised by Stephen Smalley and
>  David Quigley were fixed and resolved.
> 
> Greg KH (proposing new new patch):
>  From what I recall, yes, they were.  I'm guessing the Red Hat boot tests
>  performed by Harald confirms this.
> END CITATION (from http://lkml.org/lkml/2009/8/5/357)
> 
> I do not personally know who is Harald and whether I can trust he is really performed
> boot tests on Red Hat with SELinux enforced, but I think, that my boot test found the opposite.
> Perhaps, you, Stephen Smalley, have raised some other issues then and now I have met my own. :(
> But I am still interested to figure out, is it only me having these issues, or
> devtmpfs patch activated really brings down SELinux enabled systems (without the policy patched)?

It seems that there are a couple of problems:
- your kernel has CONFIG_DEVTMPFS=y but CONFIG_DEVTMPFS_MOUNT=n, so you
get to incur the 
- your policy doesn't allow kernel_t unfettered access to the default
type associated with devtmpfs.  That's a policy issue.

-- 
Stephen Smalley
National Security Agency

Re: System console hangs on boot in enforced unless some permissions added (with 2.6.32-3).

[Christopher J. PeBenito]

On Thu, 2010-04-29 at 09:02 -0400, Stephen Smalley wrote:
> On Thu, 2010-04-29 at 10:14 +0400, selinux@udmvt.ru wrote:
> > Yes, ofcourse, it is labelled. Plus, my little "fix" by allowing kernel_t
> > access to tmpfs_t allowed the system to properly boot and function in
> > enforced mode and transition to system services and to getty_t, etc, etc.
> > Can that happen with labelling problems?
> > And ofcourse, getty should never be in kernel_t.
> 
> Ok, I understand your problem now.
> devtmpfs internally switches to the initial task's credentials when
> performing internal operations like creating new device nodes when they
> are requested by the driver.  Otherwise we'd have to allow whatever
> happened to be the currently running process (e.g. getty_t) to perform
> those operations, whereas they aren't originating from that process at
> all and we don't want to permit the process to perform that action on
> its own.  That's why it shows up as kernel_t.  In the Fedora default
> targeted policy, kernel_t is unconfined and everything just works.  If
> we don't already have explicit allow rules permitting kernel_t to create
> these nodes in whatever default type we assign to devtmpfs, then that's
> a policy bug.

To make sure I understand correctly since I'm not versed in devtmpfs
yet, kernel_t should be able to create device nodes, directories and
symlinks in /dev?  Does it create them with the right context, or does
it rely on udev to come by and relabel them?

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] System console hangs on boot in enforced unless some permissions added (with 2.6.32-3).

[Christopher J. PeBenito]

On Thu, 2010-04-29 at 09:02 -0400, Stephen Smalley wrote:
> On Thu, 2010-04-29 at 10:14 +0400, selinux at udmvt.ru wrote:
> > Yes, ofcourse, it is labelled. Plus, my little "fix" by allowing kernel_t
> > access to tmpfs_t allowed the system to properly boot and function in
> > enforced mode and transition to system services and to getty_t, etc, etc.
> > Can that happen with labelling problems?
> > And ofcourse, getty should never be in kernel_t.
> 
> Ok, I understand your problem now.
> devtmpfs internally switches to the initial task's credentials when
> performing internal operations like creating new device nodes when they
> are requested by the driver.  Otherwise we'd have to allow whatever
> happened to be the currently running process (e.g. getty_t) to perform
> those operations, whereas they aren't originating from that process at
> all and we don't want to permit the process to perform that action on
> its own.  That's why it shows up as kernel_t.  In the Fedora default
> targeted policy, kernel_t is unconfined and everything just works.  If
> we don't already have explicit allow rules permitting kernel_t to create
> these nodes in whatever default type we assign to devtmpfs, then that's
> a policy bug.

To make sure I understand correctly since I'm not versed in devtmpfs
yet, kernel_t should be able to create device nodes, directories and
symlinks in /dev?  Does it create them with the right context, or does
it rely on udev to come by and relabel them?

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

Re: System console hangs on boot in enforced unless some permissions added (with 2.6.32-3).

[Stephen Smalley]

On Thu, 2010-04-29 at 09:57 -0400, Christopher J. PeBenito wrote:
> On Thu, 2010-04-29 at 09:02 -0400, Stephen Smalley wrote:
> > On Thu, 2010-04-29 at 10:14 +0400, selinux@udmvt.ru wrote:
> > > Yes, ofcourse, it is labelled. Plus, my little "fix" by allowing kernel_t
> > > access to tmpfs_t allowed the system to properly boot and function in
> > > enforced mode and transition to system services and to getty_t, etc, etc.
> > > Can that happen with labelling problems?
> > > And ofcourse, getty should never be in kernel_t.
> > 
> > Ok, I understand your problem now.
> > devtmpfs internally switches to the initial task's credentials when
> > performing internal operations like creating new device nodes when they
> > are requested by the driver.  Otherwise we'd have to allow whatever
> > happened to be the currently running process (e.g. getty_t) to perform
> > those operations, whereas they aren't originating from that process at
> > all and we don't want to permit the process to perform that action on
> > its own.  That's why it shows up as kernel_t.  In the Fedora default
> > targeted policy, kernel_t is unconfined and everything just works.  If
> > we don't already have explicit allow rules permitting kernel_t to create
> > these nodes in whatever default type we assign to devtmpfs, then that's
> > a policy bug.
> 
> To make sure I understand correctly since I'm not versed in devtmpfs
> yet, kernel_t should be able to create device nodes, directories and
> symlinks in /dev?  Does it create them with the right context, or does
> it rely on udev to come by and relabel them?

Based on the code, it appears to create and delete directories and
device nodes, no symlinks.  It cannot create them in the right context
since the kernel knows nothing of file_contexts, so it just creates them
in the default context, leaving it to userspace (restorecon or udev) to
assign the correct context.  It would be better if that were device_t
rather than tmpfs_t for obvious reasons.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] System console hangs on boot in enforced unless some permissions added (with 2.6.32-3).

[Stephen Smalley]

On Thu, 2010-04-29 at 09:57 -0400, Christopher J. PeBenito wrote:
> On Thu, 2010-04-29 at 09:02 -0400, Stephen Smalley wrote:
> > On Thu, 2010-04-29 at 10:14 +0400, selinux at udmvt.ru wrote:
> > > Yes, ofcourse, it is labelled. Plus, my little "fix" by allowing kernel_t
> > > access to tmpfs_t allowed the system to properly boot and function in
> > > enforced mode and transition to system services and to getty_t, etc, etc.
> > > Can that happen with labelling problems?
> > > And ofcourse, getty should never be in kernel_t.
> > 
> > Ok, I understand your problem now.
> > devtmpfs internally switches to the initial task's credentials when
> > performing internal operations like creating new device nodes when they
> > are requested by the driver.  Otherwise we'd have to allow whatever
> > happened to be the currently running process (e.g. getty_t) to perform
> > those operations, whereas they aren't originating from that process at
> > all and we don't want to permit the process to perform that action on
> > its own.  That's why it shows up as kernel_t.  In the Fedora default
> > targeted policy, kernel_t is unconfined and everything just works.  If
> > we don't already have explicit allow rules permitting kernel_t to create
> > these nodes in whatever default type we assign to devtmpfs, then that's
> > a policy bug.
> 
> To make sure I understand correctly since I'm not versed in devtmpfs
> yet, kernel_t should be able to create device nodes, directories and
> symlinks in /dev?  Does it create them with the right context, or does
> it rely on udev to come by and relabel them?

Based on the code, it appears to create and delete directories and
device nodes, no symlinks.  It cannot create them in the right context
since the kernel knows nothing of file_contexts, so it just creates them
in the default context, leaving it to userspace (restorecon or udev) to
assign the correct context.  It would be better if that were device_t
rather than tmpfs_t for obvious reasons.

-- 
Stephen Smalley
National Security Agency

Re: System console hangs on boot in enforced unless some permissions added (with 2.6.32-3).

[Christopher J. PeBenito]

On Thu, 2010-04-29 at 10:15 -0400, Stephen Smalley wrote:
> On Thu, 2010-04-29 at 09:57 -0400, Christopher J. PeBenito wrote:
> > On Thu, 2010-04-29 at 09:02 -0400, Stephen Smalley wrote:
> > > On Thu, 2010-04-29 at 10:14 +0400, selinux@udmvt.ru wrote:
> > > > Yes, ofcourse, it is labelled. Plus, my little "fix" by allowing kernel_t
> > > > access to tmpfs_t allowed the system to properly boot and function in
> > > > enforced mode and transition to system services and to getty_t, etc, etc.
> > > > Can that happen with labelling problems?
> > > > And ofcourse, getty should never be in kernel_t.
> > > 
> > > Ok, I understand your problem now.
> > > devtmpfs internally switches to the initial task's credentials when
> > > performing internal operations like creating new device nodes when they
> > > are requested by the driver.  Otherwise we'd have to allow whatever
> > > happened to be the currently running process (e.g. getty_t) to perform
> > > those operations, whereas they aren't originating from that process at
> > > all and we don't want to permit the process to perform that action on
> > > its own.  That's why it shows up as kernel_t.  In the Fedora default
> > > targeted policy, kernel_t is unconfined and everything just works.  If
> > > we don't already have explicit allow rules permitting kernel_t to create
> > > these nodes in whatever default type we assign to devtmpfs, then that's
> > > a policy bug.
> > 
> > To make sure I understand correctly since I'm not versed in devtmpfs
> > yet, kernel_t should be able to create device nodes, directories and
> > symlinks in /dev?  Does it create them with the right context, or does
> > it rely on udev to come by and relabel them?
> 
> Based on the code, it appears to create and delete directories and
> device nodes, no symlinks.  It cannot create them in the right context
> since the kernel knows nothing of file_contexts, so it just creates them
> in the default context,

Ah yes, I don't know what I was thinking.

>  leaving it to userspace (restorecon or udev) to
> assign the correct context.  It would be better if that were device_t
> rather than tmpfs_t for obvious reasons.

I suppose an interim solution would be to have a kernel_t type
transition on tmpfs_t to device_t for chr_file, blk_file, and dir, until
we can fix up the policy so devtmpfs can be device_t.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] System console hangs on boot in enforced unless some permissions added (with 2.6.32-3).

[Christopher J. PeBenito]

On Thu, 2010-04-29 at 10:15 -0400, Stephen Smalley wrote:
> On Thu, 2010-04-29 at 09:57 -0400, Christopher J. PeBenito wrote:
> > On Thu, 2010-04-29 at 09:02 -0400, Stephen Smalley wrote:
> > > On Thu, 2010-04-29 at 10:14 +0400, selinux at udmvt.ru wrote:
> > > > Yes, ofcourse, it is labelled. Plus, my little "fix" by allowing kernel_t
> > > > access to tmpfs_t allowed the system to properly boot and function in
> > > > enforced mode and transition to system services and to getty_t, etc, etc.
> > > > Can that happen with labelling problems?
> > > > And ofcourse, getty should never be in kernel_t.
> > > 
> > > Ok, I understand your problem now.
> > > devtmpfs internally switches to the initial task's credentials when
> > > performing internal operations like creating new device nodes when they
> > > are requested by the driver.  Otherwise we'd have to allow whatever
> > > happened to be the currently running process (e.g. getty_t) to perform
> > > those operations, whereas they aren't originating from that process at
> > > all and we don't want to permit the process to perform that action on
> > > its own.  That's why it shows up as kernel_t.  In the Fedora default
> > > targeted policy, kernel_t is unconfined and everything just works.  If
> > > we don't already have explicit allow rules permitting kernel_t to create
> > > these nodes in whatever default type we assign to devtmpfs, then that's
> > > a policy bug.
> > 
> > To make sure I understand correctly since I'm not versed in devtmpfs
> > yet, kernel_t should be able to create device nodes, directories and
> > symlinks in /dev?  Does it create them with the right context, or does
> > it rely on udev to come by and relabel them?
> 
> Based on the code, it appears to create and delete directories and
> device nodes, no symlinks.  It cannot create them in the right context
> since the kernel knows nothing of file_contexts, so it just creates them
> in the default context,

Ah yes, I don't know what I was thinking.

>  leaving it to userspace (restorecon or udev) to
> assign the correct context.  It would be better if that were device_t
> rather than tmpfs_t for obvious reasons.

I suppose an interim solution would be to have a kernel_t type
transition on tmpfs_t to device_t for chr_file, blk_file, and dir, until
we can fix up the policy so devtmpfs can be device_t.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

Re: System console hangs on boot in enforced unless some permissions added (with 2.6.32-3).

[selinux]

On Thu, Apr 29, 2010 at 10:43:33AM -0400, Christopher J. PeBenito wrote:
> On Thu, 2010-04-29 at 10:15 -0400, Stephen Smalley wrote:
> > > symlinks in /dev?  Does it create them with the right context, or does
> > > it rely on udev to come by and relabel them?
> > 
> > Based on the code, it appears to create and delete directories and
> > device nodes, no symlinks.  It cannot create them in the right context
> > since the kernel knows nothing of file_contexts, so it just creates them
> > in the default context,
> 
> Ah yes, I don't know what I was thinking.
> 
> >  leaving it to userspace (restorecon or udev) to
> > assign the correct context.  It would be better if that were device_t
> > rather than tmpfs_t for obvious reasons.
> 
> I suppose an interim solution would be to have a kernel_t type
> transition on tmpfs_t to device_t for chr_file, blk_file, and dir, until
> we can fix up the policy so devtmpfs can be device_t.

That sounds like a good solution. In my case of unmounted devtmpfs
it will be preferable to create a separate type for this with no attributes
and no allow rules except for kernel_t.

But I wonder if it would break something else...

Thanks for your help, but anyway, I'm going to contact Debian people with this issue.

-- 
Alexey S.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.