'unable to relabel' in /dev.... MAKEDEV-3.7-2

[Tom London]

Running off of the development tree, MAKEDEV-3.7-2 creates lots of new 
files. Running 'fixfiles relabel' or 'setfiles -v $FC /dev' generates 
lots of error messages like:

/dev/ptyu7: Permission denied
/usr/sbin/setfiles:  unable to relabel /dev/ptyu7 to 
system_u:object_r:device_t
/dev/ptyd7: Permission denied
/usr/sbin/setfiles:  unable to relabel /dev/ptyd7 to 
system_u:object_r:device_t
/dev/ptyde: Permission denied
/usr/sbin/setfiles:  unable to relabel /dev/ptyde to 
system_u:object_r:device_t
/dev/ptyac: Permission denied
/usr/sbin/setfiles:  unable to relabel /dev/ptyac to 
system_u:object_r:device_t
/dev/ptys1: Permission denied
/usr/sbin/setfiles:  unable to relabel /dev/ptys1 to 
system_u:object_r:device_t
/dev/ircomm9: Permission denied
/usr/sbin/setfiles:  unable to relabel /dev/ircomm9 to 
system_u:object_r:device_t
/dev/ptyre: Permission denied
/usr/sbin/setfiles:  unable to relabel /dev/ptyre to 
system_u:object_r:device_t

Here is an 'ls -l' of one of the files:
[root@dell dev]# ls -l ptyu7
crw-rw-rw-  1 root tty 2, 87 Jun 14 12:42 ptyu7
[root@dell dev]# ls -lZ $_
crw-rw-rw-  root     tty      root:object_r:device_t           ptyu7
[root@dell dev]#

I'm running selinux-policy-strict-1.13.4-6, with file_contexts augmented 
with Russell Coker's fix for /udev/microcode.

tom

'unable to relabel' in /dev.... MAKEDEV-3.7-2, AVCs provided

[Tom London]

Relabeling works in permissive mode.

I worked around a broken sysklogd to get AVCs for this.  These were 
produced by running 'restorecon -v /dev/ircomm0; setenforce 0; 
restorecon -v /dev/ircomm0':

audit(1087336052.916:0): avc:  denied  { relabelto } for  pid=4459 
exe=/sbin/restorecon name=ircomm0 dev=hdb3 ino=153075 
scontext=root:sysadm_r:restorecon_t tcontext=system_u:object_r:device_t 
tclass=chr_file
audit(1087336122.785:0): avc:  granted  { setenforce } for  pid=4461 
exe=/usr/bin/setenforce scontext=root:sysadm_r:sysadm_t 
tcontext=system_u:object_r:security_t tclass=security
audit(1087336125.404:0): avc:  denied  { relabelto } for  pid=4462 
exe=/sbin/restorecon name=ircomm0 dev=hdb3 ino=153075 
scontext=root:sysadm_r:restorecon_t tcontext=system_u:object_r:device_t 
tclass=chr_file

I'm confused.... restorecon.te has entries:
allow restorecon_t device_type:{ chr_file blk_file } { getattr 
relabelfrom relabelto };
allow restorecon_t device_t:{ chr_file blk_file } { getattr relabelfrom };

The AVCs imply 'relabelto' is needed on the second line too, or is this 
an issue with MAKEDEV creating the files improperly?

tom

Tom London wrote:
> Running off of the development tree, MAKEDEV-3.7-2 creates lots of new 
> files. Running 'fixfiles relabel' or 'setfiles -v $FC /dev' generates 
> lots of error messages like:
>
> /dev/ptyu7: Permission denied
> /usr/sbin/setfiles:  unable to relabel /dev/ptyu7 to 
> system_u:object_r:device_t
> /dev/ptyd7: Permission denied
> /usr/sbin/setfiles:  unable to relabel /dev/ptyd7 to 
> system_u:object_r:device_t
> /dev/ptyde: Permission denied
> /usr/sbin/setfiles:  unable to relabel /dev/ptyde to 
> system_u:object_r:device_t
> /dev/ptyac: Permission denied
> /usr/sbin/setfiles:  unable to relabel /dev/ptyac to 
> system_u:object_r:device_t
> /dev/ptys1: Permission denied
> /usr/sbin/setfiles:  unable to relabel /dev/ptys1 to 
> system_u:object_r:device_t
> /dev/ircomm9: Permission denied
> /usr/sbin/setfiles:  unable to relabel /dev/ircomm9 to 
> system_u:object_r:device_t
> /dev/ptyre: Permission denied
> /usr/sbin/setfiles:  unable to relabel /dev/ptyre to 
> system_u:object_r:device_t
>
> Here is an 'ls -l' of one of the files:
> [root@dell dev]# ls -l ptyu7
> crw-rw-rw-  1 root tty 2, 87 Jun 14 12:42 ptyu7
> [root@dell dev]# ls -lZ $_
> crw-rw-rw-  root     tty      root:object_r:device_t           ptyu7
> [root@dell dev]#
>
> I'm running selinux-policy-strict-1.13.4-6, with file_contexts 
> augmented with Russell Coker's fix for /udev/microcode.
>
> tom

'unable to relabel' in /dev.... MAKEDEV-3.7-2, AVCs provided

[Russell Coker]

On Wed, 16 Jun 2004 08:07, Tom London  wrote:
> I'm confused.... restorecon.te has entries:
> allow restorecon_t device_type:{ chr_file blk_file } { getattr
> relabelfrom relabelto };
> allow restorecon_t device_t:{ chr_file blk_file } { getattr relabelfrom };

Ideally there should be no device nodes with type device_t, we should have 
correct labels assigned to all of them.  Therefore changing a label from 
something in device_type to device_t is generally not desired.

'unable to relabel' in /dev.... MAKEDEV-3.7-2, AVCs provided

[Tom London]

OK.  I think I understand what is going on:

Some of the packages in the development tree do not have context labels, 
that is,
'rpm -q --filecontext MAKEDEV' shows no context labels (just file names).
So the special files in /dev got created with type 'device_t'.... sigh.

I'm guessing that as we get closer to 'release' or 'update' packages 
this will not be as big
a problem.

In the interim, I'll stick with running something like
        rpm -ql Package | xargs restorecon
after installs/upgrades.

Its what I deserve for running off of the development tree!

thanks,
  tom

Russell Coker wrote:
> On Wed, 16 Jun 2004 08:07, Tom London  wrote:
> > I'm confused.... restorecon.te has entries:
> > allow restorecon_t device_type:{ chr_file blk_file } { getattr
> > relabelfrom relabelto };
> > allow restorecon_t device_t:{ chr_file blk_file } { getattr relabelfrom };
>
> Ideally there should be no device nodes with type device_t, we should have 
> correct labels assigned to all of them.  Therefore changing a label from 
> something in device_type to device_t is generally not desired.

[Russell Coker]

On Wed, 16 Jun 2004 03:13, Tom London  wrote:
> Running off of the development tree, MAKEDEV-3.7-2 creates lots of new
> files. Running 'fixfiles relabel' or 'setfiles -v $FC /dev' generates
> lots of error messages like:
>
> /dev/ptyu7: Permission denied
> /usr/sbin/setfiles:  unable to relabel /dev/ptyu7 to
> system_u:object_r:device_t

The /dev/[tp]ty[abcdepqrstuvwxyz][0-9a-f] device nodes do not work on SE Linux 
and almost certainly never will.

I am under the impression that /dev/[tp]ty* are strongly deprecated and not 
used in any software we ship.  Is it time to completely remove them from 
Fedora?

[Alan Cox]

On Wed, Jun 16, 2004 at 11:54:24AM +1000, Russell Coker wrote:
> I am under the impression that /dev/[tp]ty* are strongly deprecated and not 
> used in any software we ship.  Is it time to completely remove them from 
> Fedora?

Some third party software still uses them. If they don't work with SELinux
I don't see a problem in them still being there.

On Wed, 16 Jun 2004 03:54:12 EDT, Alan Cox said:
> On Wed, Jun 16, 2004 at 11:54:24AM +1000, Russell Coker wrote:
> > I am under the impression that /dev/[tp]ty* are strongly deprecated and not
> > used in any software we ship.  Is it time to completely remove them from 
> > Fedora?
>
> Some third party software still uses them. If they don't work with SELinux
> I don't see a problem in them still being there.

Looks like Linus picked up the LEGACY_PTY support back around
2.6.4-rc1 back in February, and nobody's said much about finding anything
that was impacted by it.  At the time, there was a lot of discussion and
not many people mentioned any actual users of BSD ptys....

I don't see any reason that Fedora couldn't change the kernel config default
to 'CONFIG_LEGACY_PTY=n' in the devel tree and see if anybody notices.
It's certainly less intrusive than dropping exec-shield in and seeing who noticed,
and THAT was considered acceptable...