Bug 1015300 - Request for SELinux Context label for udev devices [NEEDINFO]
Summary: Request for SELinux Context label for udev devices
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: udev
Version: 6.4
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Harald Hoyer
QA Contact: Radka Skvarilova
Jana Heves
URL:
Whiteboard:
Depends On:
Blocks: 1270825
TreeView+ depends on / blocked
 
Reported: 2013-10-03 21:03 UTC by rlopez
Modified: 2016-05-11 00:25 UTC (History)
9 users (show)

Fixed In Version: udev-147-2.72.el6
Doc Type: Enhancement
Doc Text:
Setting an SELinux context label for a block device To be able to label device nodes, most commonly disks, as used by certain applications, this update provides the possibility to apply SELinux labels on device nodes created by *udev*. The system administrator can set a new option to give a label to a newly created device node as follows: SECLABEL{selinux}="label"
Clone Of:
Environment:
Last Closed: 2016-05-11 00:25:56 UTC
Target Upstream Version:
msekleta: needinfo? (rlopez)


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:0903 normal SHIPPED_LIVE udev bug fix update 2016-05-10 22:51:07 UTC

Description rlopez 2013-10-03 21:03:55 UTC
Description of problem:

Currently, one can create udev rules to apply an owner,group, and mode to a block device, however there is no way of setting an SELinux context label for a block device within udev rules. Would it be possible to have a udev rule that looks like the following where there is some 'SELINUX_LABEL' that takes a value?

KERNEL=="dm-*",ENV{DM_UUID}=="part1-mpath-36019cb11200c5622db213503f8b51940",OWNER="grid",GROUP="asmadmin",MODE="0660",SELINUX_LABEL="sometype_t"

The reason for the request is I'm currently working with Dan Walsh on creating an SELinux policy for Oracle environments. One of the requirements would be to properly label disks that will be used by Oracle. 

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Daniel Walsh 2013-10-04 13:00:57 UTC
KERNEL=="dm-*",ENV{DM_UUID}=="part1-mpath-36019cb11200c5622db213503f8b51940",OWNER="grid",GROUP="asmadmin",MODE="0660",SELINUX_LABEL="system_u:object_r:oracle_db_t:s0"

Would be a better description.

Harald is there a way I can do this today?

Maybe we need this feature in Rawhide if we could implement it via a script today in RHEL6.

Comment 3 Harald Hoyer 2013-10-07 15:22:05 UTC
(In reply to Daniel Walsh from comment #2)
> KERNEL=="dm-*",ENV{DM_UUID}=="part1-mpath-36019cb11200c5622db213503f8b51940",
> OWNER="grid",GROUP="asmadmin",MODE="0660",SELINUX_LABEL="system_u:object_r:
> oracle_db_t:s0"
> 
> Would be a better description.
> 
> Harald is there a way I can do this today?
> 
> Maybe we need this feature in Rawhide if we could implement it via a script
> today in RHEL6.

no way from udev today, that I know of. I am sorry.

http://cgit.freedesktop.org/systemd/systemd/tree/libudev/libudev-selinux-private.c?id=09637f743414e2c36d6c5b032d77d76dbeb86b31

is all we use with selinux in RHEL-6

Comment 4 Kay Sievers 2013-10-07 15:46:28 UTC
(In reply to Daniel Walsh from comment #2)
> KERNEL=="dm-*",ENV{DM_UUID}=="part1-mpath-36019cb11200c5622db213503f8b51940",
> OWNER="grid",GROUP="asmadmin",MODE="0660",SELINUX_LABEL="system_u:object_r:
> oracle_db_t:s0"
> 
> Would be a better description.
> 
> Harald is there a way I can do this today?

So far there are no raw selinux labels anywhere in any udev-related config.
Is that really the way things should work, it's nothing that the policy
would/can carry out?

It's relatively easy to implement the above, but it seems like a departure from
the current model? That's fine?

Comment 5 Daniel Walsh 2013-10-07 16:12:18 UTC
What we are trying to get to is a way for an administrator to say that oracle data is going to be on these devices/disks.  Currently we label content via path or "SELinux Intelligent" applications, like libvirt on /dev.

But in this case we have no way for the people who want to confine an oracle application that used physical devices to label the devices when they show up.  They can do this with the UID/GID, so we should allow them to do it with the SELinux context.

I could see this with other potential types of devices to say the device contains apache content or it contains user home dir content or even top_secret data.

Comment 6 Kay Sievers 2013-10-08 00:30:04 UTC
Udev supports now:
  SECLABEL{selinux}="$name"

The logic was added here:
  http://cgit.freedesktop.org/systemd/systemd/commit/?id=c26547d612733371494330e26c7d3604a5dba3d9

The selinux code will be added here:
  "/* FIXME: hook up libselinux */"

Dan, could you provide/paste the needed calls for selinux to apply a custom
label from the string we get from the udev rules? Thanks!

Comment 7 Daniel Walsh 2013-10-09 13:59:32 UTC
Here is all that is needed.

if (setfilecon(devnode, label) < 0)
    log_error("SECLABEL: failed to set SELinux label '%s'", label);
else
    log_debug("SECLABEL: set SELinux label '%s'", label);

Comment 8 Kay Sievers 2013-10-09 15:40:15 UTC
Thanks!

SECLABEL{selinux}+="foo" should work in systemd git now.

(It is possible to backport it to RHEL7, but it will not really work for RHEL6.)

Comment 9 Daniel Walsh 2013-10-09 16:03:15 UTC
Well it is a great new feature for RHEL7...

Comment 10 Harald Hoyer 2013-10-11 08:56:47 UTC
(In reply to Daniel Walsh from comment #9)
> Well it is a great new feature for RHEL7...

So, can I devel_ack- for RHEL-6? Or is this crucial? You can always to RUN+="" with the selinux util to set the label.

Comment 11 rlopez 2013-10-11 16:40:07 UTC
(In reply to Harald Hoyer from comment #10)
> (In reply to Daniel Walsh from comment #9)
> > Well it is a great new feature for RHEL7...
> 
> So, can I devel_ack- for RHEL-6? Or is this crucial? You can always to
> RUN+="" with the selinux util to set the label.

Hi Harold, if I try and supply a udev rule as follows:

KERNEL=="dm-*",ENV{DM_UUID}=="part1-mpath-36019cb11200c5622db213503f8b51940",OWNER="grid",GROUP="asmadmin",MODE="0660",RUN+="semanage fcontext -a -t oracle_db_t /dev/mapper/db1p1"

Where in this case this command "semanage fcontext -a -t oracle_db_t /dev/mapper/db1p1" if run at a shell would change the label of /dev/mapper/db1p1 from device_t to oracle_db_t

Am I just running this incorrectly? 

db1p1 maps as /dev/mapper/db1p1 -> dm-10. When I try the command:
 udevadm test /sys/block/dm-10

This produces lots of output but I do see: 
udev_rules_apply_to_event: RUN 'semanage fcontext -a -t oracle_db_t /dev/mapper/db1p1' /etc/udev/rules.d/99-oracle-asmdevices.rules:1
udev_event_execute_rules: no node name set, will use kernel supplied name 'dm-10'

Comment 12 Daniel Walsh 2013-10-11 17:16:06 UTC
rlopez wrong command 

try it with chcon.  You do not want to run semanage here.

chcon -t oracle_db_t /dev/mapper/db1p1

Should work.

Harald if this works for RHEL6 then I would close this bug for RHEL6.

Comment 13 rlopez 2013-10-11 20:24:13 UTC
(In reply to Daniel Walsh from comment #12)
> rlopez wrong command 
> 
> try it with chcon.  You do not want to run semanage here.
> 
> chcon -t oracle_db_t /dev/mapper/db1p1
> 
> Should work.
> 
> Harald if this works for RHEL6 then I would close this bug for RHEL6.

Harald,

The problem we currently have is that /dev/mapper devices are symbolic links mapping to a dm-* device which changes upon a reboot. The goal is to set an SELinux label to the dm-* device.

For example the reason we have the udev rule:
KERNEL=="dm-*",ENV{DM_UUID}=="part1-mpath-36019cb11200c5622db213503f8b51940",OWNER="grid",GROUP="asmadmin",MODE="0660"

Is because we want the owner grid and the group asmadmin to own this particular disk. If we do the following commands:

[root@spr1 ~]# ls -Z /dev/mapper/db1p1 
lrwxrwxrwx. root root system_u:object_r:device_t:s0    /dev/mapper/db1p1 -> ../dm-12
[root@spr1 ~]# ls -Z /dev/dm-12
brw-rw----. grid asmadmin system_u:object_r:fixed_disk_device_t:s0 /dev/dm-12

You can see that db1p1 points to dm-12 and dm-12 has the owner grid and the group asmadmin. 

Now to the SELinux, if I use the chcon command as dwalsh mentioned:
chcon -t oracle_db_t /dev/mapper/db1p1 , from a shell this will change the context of that /dev/mapper/db1p1 from device_t to oracle_db_t, however if I put that same command in the RUN+="chcon -t oracle_db_t /dev/mapper/db1p1" it does not change the labeling. Ideally the oracle_db_t label would get passed down to the dm-* device just like how we set OWNER= and GROUP=. Is there anything I can do with RUN to accomplish this? Is there a way to see why the current RUN+="chcon -t oracle_db_t /dev/mapper/db1p1" doesn't relabel? Is it possible that the labeling is happening, yet udev is relabeling back to its original label?

Comment 14 RHEL Program Management 2013-10-15 01:35:20 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 15 Harald Hoyer 2013-10-31 12:16:59 UTC
(In reply to rlopez from comment #13)
> (In reply to Daniel Walsh from comment #12)
> > rlopez wrong command 
> > 
> > try it with chcon.  You do not want to run semanage here.
> > 
> > chcon -t oracle_db_t /dev/mapper/db1p1
> > 
> > Should work.
> > 
> > Harald if this works for RHEL6 then I would close this bug for RHEL6.
> 
> Harald,
> 
> The problem we currently have is that /dev/mapper devices are symbolic links
> mapping to a dm-* device which changes upon a reboot. The goal is to set an
> SELinux label to the dm-* device.
> 
> For example the reason we have the udev rule:
> KERNEL=="dm-*",ENV{DM_UUID}=="part1-mpath-36019cb11200c5622db213503f8b51940",
> OWNER="grid",GROUP="asmadmin",MODE="0660"
> 
> Is because we want the owner grid and the group asmadmin to own this
> particular disk. If we do the following commands:
> 
> [root@spr1 ~]# ls -Z /dev/mapper/db1p1 
> lrwxrwxrwx. root root system_u:object_r:device_t:s0    /dev/mapper/db1p1 ->
> ../dm-12
> [root@spr1 ~]# ls -Z /dev/dm-12
> brw-rw----. grid asmadmin system_u:object_r:fixed_disk_device_t:s0 /dev/dm-12
> 
> You can see that db1p1 points to dm-12 and dm-12 has the owner grid and the
> group asmadmin. 
> 
> Now to the SELinux, if I use the chcon command as dwalsh mentioned:
> chcon -t oracle_db_t /dev/mapper/db1p1 , from a shell this will change the
> context of that /dev/mapper/db1p1 from device_t to oracle_db_t, however if I
> put that same command in the RUN+="chcon -t oracle_db_t /dev/mapper/db1p1"
> it does not change the labeling. Ideally the oracle_db_t label would get
> passed down to the dm-* device just like how we set OWNER= and GROUP=. Is
> there anything I can do with RUN to accomplish this? Is there a way to see
> why the current RUN+="chcon -t oracle_db_t /dev/mapper/db1p1" doesn't
> relabel? Is it possible that the labeling is happening, yet udev is
> relabeling back to its original label?

It has to be /bin/chcon

 RUN+="/bin/chcon -t oracle_db_t /dev/mapper/db1p1"

and you don't want to use the device name.

RUN+="/bin/chcon -t oracle_db_t $env{DEVNAME} $env{DEVLINKS}"

Comment 16 Daniel Walsh 2013-11-01 16:30:28 UTC
rlopez has gotten this working, hopefully he will chime in.

Comment 17 rlopez 2013-11-01 19:09:18 UTC
(In reply to Daniel Walsh from comment #16)
> rlopez has gotten this working, hopefully he will chime in.

Hi Harald and Dan,

I created a script called 'oracle_chcon.sh' that passes a value and runs the chcon command. Via the RUN command, if you try and pass chcon directly, it will not work i.e. RUN+="/usr/bin/chcon -t oracle_db_t $env{DEVNAME} does *NOT* work. 

What one of my udev rule looks like:
KERNEL=="dm-*",ENV{DM_UUID}=="part1-mpath-36019cb11200c5622db213503f8b51940",OWNER="grid",GROUP="asmadmin",MODE="0660",RUN+="/root/oracle_chcon.sh $env{DEVNAME}" 

The oracle_chon script contains the following:

cat /root/oracle_chcon.sh
#!/bin/bash

chcon -t oracle_db_t $1

Output of my /dev/dm-10 device:
ls -Z /dev/dm-10
brw-rw----. grid asmadmin system_u:object_r:oracle_db_t:s0 /dev/dm-10

Comment 18 Harald Hoyer 2013-11-04 16:27:55 UTC
(In reply to rlopez from comment #17)
> RUN+="/usr/bin/chcon -t oracle_db_t $env{DEVNAME} does
> *NOT* work. 
> 

I guess, because it's /bin/chcon and _NOT_ /usr/bin/chcon ??

Comment 19 rlopez 2013-11-04 17:36:21 UTC
(In reply to Harald Hoyer from comment #18)
> (In reply to rlopez from comment #17)
> > RUN+="/usr/bin/chcon -t oracle_db_t $env{DEVNAME} does
> > *NOT* work. 
> > 
> 
> I guess, because it's /bin/chcon and _NOT_ /usr/bin/chcon ??

I just tried /bin/chcon and it didn't work. When I do the command 'which chcon' it shows /usr/bin/chcon

Comment 20 Harald Hoyer 2015-02-27 13:09:29 UTC
(In reply to rlopez from comment #17)
> (In reply to Daniel Walsh from comment #16)
> > rlopez has gotten this working, hopefully he will chime in.
> 
> Hi Harald and Dan,
> 
> I created a script called 'oracle_chcon.sh' that passes a value and runs the
> chcon command. Via the RUN command, if you try and pass chcon directly, it
> will not work i.e. RUN+="/usr/bin/chcon -t oracle_db_t $env{DEVNAME} does
> *NOT* work. 
> 
> What one of my udev rule looks like:
> KERNEL=="dm-*",ENV{DM_UUID}=="part1-mpath-36019cb11200c5622db213503f8b51940",
> OWNER="grid",GROUP="asmadmin",MODE="0660",RUN+="/root/oracle_chcon.sh
> $env{DEVNAME}" 
> 
> The oracle_chon script contains the following:
> 
> cat /root/oracle_chcon.sh
> #!/bin/bash
> 
> chcon -t oracle_db_t $1
> 
> Output of my /dev/dm-10 device:
> ls -Z /dev/dm-10
> brw-rw----. grid asmadmin system_u:object_r:oracle_db_t:s0 /dev/dm-10

Just do in the shell script at the beginning:
set -x
exec >>/dev/.udev/oracle-log.txt 2>>/dev/.udev/oracle-log.txt

and inspect the log later on

Comment 22 Michal Sekletar 2015-11-16 14:42:57 UTC
Is this still an issue?

Comment 23 Michal Sekletar 2016-01-04 09:52:01 UTC
I've prepared backport of SECLABEL feature for RHEL-6. I did some basic testing and it seems to work fine, but I'd be glad if someone else could also give it a try.

Here are test packages,
http://people.redhat.com/~msekleta/udev-147-2.66.el6/

Comment 28 errata-xmlrpc 2016-05-11 00:25:56 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-0903.html


Note You need to log in before you can comment on or make changes to this bug.