automatic type transitions for pts in devfs

automatic type transitions for pts in devfs

[Russell Coker]

It seems that the automatic type transitions for /dev/pts don't work on 
devfs.  When the sshd (in sshd_t domain) opens /dev/pts/1 it does not get 
changed to sshd_devpts_t domain.

When I put the following in my devfs_contexts file it all works as desired 
(so my only problem is the sshd_t causing a transition of the /dev/pts/1 
device node to sshd_devpts_t.
/pts                    system_u:object_r:sshd_devpts_t

I'm using the default sshd configuration.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux 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: automatic type transitions for pts in devfs

[Stephen Smalley]

On Wed, 6 Mar 2002, Russell Coker wrote:

> It seems that the automatic type transitions for /dev/pts don't work on
> devfs.  When the sshd (in sshd_t domain) opens /dev/pts/1 it does not get
> changed to sshd_devpts_t domain.

Right.  The initial labeling of pty nodes based on the allocating process
domain is only implemented for the devpts filesystem at present, not the
devfs filesystem.  The SELinux kernel module performs special processing
for the devpts filesystem type to ensure that new nodes are initially
labeled with the type specified by a type transition rule between the
domain that initially allocated the pty and the base devpts_t type.  When
sshd or rlogind allocate a pty in a devpts filesystem, it is initially
labeled by the kernel with a sshd_devpts_t or rlogind_devpts_t type and is
subsequently relabeled by sshd or login to the appropriate user_devpts_t or
sysadm_devpts_t type.  When a user runs X, his ptys are initially
allocated from the user_t or sysadm_t domain, so they are immediately
labeled with user_devpts_t or sysadm_devpts_t by the kernel.

At present, we don't use devfs on our systems, so it hasn't (yet) been a
priority to provide identical functionality in devfs.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com





--
You have received this message because you are subscribed to the selinux 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: automatic type transitions for pts in devfs

[Russell Coker]

On Wed, 6 Mar 2002 14:41, Stephen Smalley wrote:
> On Wed, 6 Mar 2002, Russell Coker wrote:
> > It seems that the automatic type transitions for /dev/pts don't work on
> > devfs.  When the sshd (in sshd_t domain) opens /dev/pts/1 it does not get
> > changed to sshd_devpts_t domain.
>
> Right.  The initial labeling of pty nodes based on the allocating process
> domain is only implemented for the devpts filesystem at present, not the
[...]
> At present, we don't use devfs on our systems, so it hasn't (yet) been a
> priority to provide identical functionality in devfs.

I've tried patching that myself, but it seems that my skills are not up to it.

It seems that the filp->f_owner.pid is being set in the devfs initialisation 
code somehow at an earlier stage than in devpts, therefore by the time 
tty_fasync() is called it's already done and the set_fowner() call is skipped.

Could you give me a clue as to where I should look next?  Or would you 
recommend that I give up?

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux 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.

automatic type transitions for pts in devfs

[Debian User]

Whats best way to go about this? Where do i look first? I will try 
fixing this with some help.

Russell?

Is there a work around for this?


--
You have received this message because you are subscribed to the selinux 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: automatic type transitions for pts in devfs

[Stephen Smalley]

On Tue, 9 Jul 2002, Debian User wrote:

> Whats best way to go about this? Where do i look first? I will try
> fixing this with some help.

You can look at how we provide labeling for the devpts filesystem.  The
devpts filesystem uses transition SIDs to label its inodes.  Look at the
sbsec->uses_trans case of inode_precondition in
lsm-2.4/security/selinux/hooks.c.  The devfs filesystem uses
genfs_contexts to label its inodes (the sbsec->uses_genfs case).  You want
devfs to actually be a hybrid of the two methods, with /pts entries
in devfs using transition SIDs like devpts and other entries using
genfs_contexts.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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: automatic type transitions for pts in devfs

[Debian User]

Stephen Smalley wrote:

>On Tue, 9 Jul 2002, Debian User wrote:
>
>  
>
>>Whats best way to go about this? Where do i look first? I will try
>>fixing this with some help.
>>    
>>
>
>You can look at how we provide labeling for the devpts filesystem.  The
>devpts filesystem uses transition SIDs to label its inodes.  Look at the
>sbsec->uses_trans case of inode_precondition in
>lsm-2.4/security/selinux/hooks.c.  The devfs filesystem uses
>genfs_contexts to label its inodes (the sbsec->uses_genfs case).  You want
>devfs to actually be a hybrid of the two methods, with /pts entries
>in devfs using transition SIDs like devpts and other entries using
>genfs_contexts.
>  
>
I see im beginning to see things clearly.  Are all the stuff involved in 
this restricted to hooks.c? Im afraid im not familiar with lsm. I have 
to look for an introduction somewhere.

>--
>Stephen D. Smalley, NAI Labs
>ssmalley@nai.com
>
>
>  
>




--
You have received this message because you are subscribed to the selinux 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: automatic type transitions for pts in devfs

[Debian User]

Stephen Smalley wrote:

>On Tue, 9 Jul 2002, Debian User wrote:
>
>  
>
>>Whats best way to go about this? Where do i look first? I will try
>>fixing this with some help.
>>    
>>
>
>You can look at how we provide labeling for the devpts filesystem.  The
>devpts filesystem uses transition SIDs to label its inodes.  Look at the
>sbsec->uses_trans case of inode_precondition in
>lsm-2.4/security/selinux/hooks.c.  The devfs filesystem uses
>genfs_contexts to label its inodes (the sbsec->uses_genfs case).  You want
>devfs to actually be a hybrid of the two methods, with /pts entries
>in devfs using transition SIDs like devpts and other entries using
>genfs_contexts.
>  
>
Ok I just read through the technical paper.
So I focus on hooks.c. This is basically getting the inodes labelled 
correctly.
Either we add some new fields(?) in the inode structure or we insert a 
condition that would make the inode get the proper label. Is that correct?

I hope someone can beat me to the answer.

>--
>Stephen D. Smalley, NAI Labs
>ssmalley@nai.com
>
>
>  
>




--
You have received this message because you are subscribed to the selinux 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: automatic type transitions for pts in devfs

[Stephen Smalley]

On Tue, 9 Jul 2002, Debian User wrote:

> Are all the stuff involved in this restricted to hooks.c?

You can implement a quick-and-dirty solution entirely by modifying
hooks.c.  A more general solution will require changes to the security
server and the policy configuration to support such hybrid schemes.

> Im afraid im not familiar with lsm. I have
> to look for an introduction somewhere.

lsm.immunix.org has some documentation about LSM.  The NSA SELinux site
has a technical report describing the implementation of the LSM-based
SELinux module, although it is not entirely up-to-date.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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: automatic type transitions for pts in devfs

[Stephen Smalley]

On Tue, 9 Jul 2002, Debian User wrote:

> So I focus on hooks.c. This is basically getting the inodes labelled
> correctly.
> Either we add some new fields(?) in the inode structure or we insert a
> condition that would make the inode get the proper label. Is that correct?

You could add a test within the sbsec->uses_genfs case to see whether the
filesystem type is devfs and whether the inode corresponds to a /pts node.
If so, then you want to use a transition SID as with the sbsec->uses_trans
case.  Otherwise, you would use genfs_contexts as usual.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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: automatic type transitions for pts in devfs

[Debian User]

Stephen Smalley wrote:

>On Tue, 9 Jul 2002, Debian User wrote:
>
>  
>
>>Are all the stuff involved in this restricted to hooks.c?
>>    
>>
>
>You can implement a quick-and-dirty solution entirely by modifying
>hooks.c.  A more general solution will require changes to the security
>server and the policy configuration to support such hybrid schemes.
>  
>
I will try the quick and dirty solution. I have an idea where to look. I 
just read some papers and its very enlightening. It looks  like i need 
to wrap the present set of nested ifs with another that tests some 
variables to get inode properly labeled.

>  
>
>>Im afraid im not familiar with lsm. I have
>>to look for an introduction somewhere.
>>    
>>
>
>lsm.immunix.org has some documentation about LSM.  The NSA SELinux site
>has a technical report describing the implementation of the LSM-based
>SELinux module, although it is not entirely up-to-date.
>
>--
>Stephen D. Smalley, NAI Labs
>ssmalley@nai.com
>
>
>  
>




--
You have received this message because you are subscribed to the selinux 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: automatic type transitions for pts in devfs

[Debian User]

Stephen Smalley wrote:

>On Tue, 9 Jul 2002, Debian User wrote:
>
>  
>
>>So I focus on hooks.c. This is basically getting the inodes labelled
>>correctly.
>>Either we add some new fields(?) in the inode structure or we insert a
>>condition that would make the inode get the proper label. Is that correct?
>>    
>>
>
>You could add a test within the sbsec->uses_genfs case to see whether the
>filesystem type is devfs and whether the inode corresponds to a /pts node.
>If so, then you want to use a transition SID as with the sbsec->uses_trans
>case.  Otherwise, you would use genfs_contexts as usual.
>  
>
cool! i see it now. this is great. this is the first time i hacked devfs 
and selinux!
Thanks!

>--
>Stephen D. Smalley, NAI Labs
>ssmalley@nai.com
>
>
>  
>




--
You have received this message because you are subscribed to the selinux 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: automatic type transitions for pts in devfs

[Debian User]

Stephen Smalley wrote:

>On Tue, 9 Jul 2002, Debian User wrote:
>
>  
>
>>So I focus on hooks.c. This is basically getting the inodes labelled
>>correctly.
>>Either we add some new fields(?) in the inode structure or we insert a
>>condition that would make the inode get the proper label. Is that correct?
>>    
>>
>
>You could add a test within the sbsec->uses_genfs case to see whether the
>filesystem type is devfs and whether the inode corresponds to a /pts node.
>If so, then you want to use a transition SID as with the sbsec->uses_trans
>case.  Otherwise, you would use genfs_contexts as usual.
>  
>
That would mean checking if the inode's super block magic number is DEVPTS.
Is that going to be enough?

>--
>Stephen D. Smalley, NAI Labs
>ssmalley@nai.com
>
>
>  
>




--
You have received this message because you are subscribed to the selinux 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.

automatic type transitions for pts in devfs

[Debian User]

my patch works with russell's devfsd-se.so disabled. just remove any selinux* 
file in /etc/devfs/conf.d. i will see if removing only the pts entry in the selinux 
conf.d file will work. 

--
You have received this message because you are subscribed to the selinux 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: automatic type transitions for pts in devfs

[Stephen Smalley]

On Thu, 11 Jul 2002, Debian User wrote:

> my patch works with russell's devfsd-se.so disabled. just remove any selinux*
> file in /etc/devfs/conf.d. i will see if removing only the pts entry in the selinux
> conf.d file will work.

This makes sense.  As long as devfsd does not intercept the registration
of pts nodes and perform a lookup at that time, your patch should work for
labeling pts nodes with transition SIDs.

This is good, as it removes the immediate need to patch devfsd.  However,
it will still be necessary to patch the kernel devfs code to preserve SIDs
on devfs entries when they are evicted from the dcache.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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: automatic type transitions for pts in devfs

[Debian User]

Stephen Smalley wrote:

>On Thu, 11 Jul 2002, Debian User wrote:
>
>  
>
>>my patch works with russell's devfsd-se.so disabled. just remove any selinux*
>>file in /etc/devfs/conf.d. i will see if removing only the pts entry in the selinux
>>conf.d file will work.
>>    
>>
>
>This makes sense.  As long as devfsd does not intercept the registration
>of pts nodes and perform a lookup at that time, your patch should work for
>labeling pts nodes with transition SIDs.
>
>This is good, as it removes the immediate need to patch devfsd.  However,
>it will still be necessary to patch the kernel devfs code to preserve SIDs
>on devfs entries when they are evicted from the dcache.
>
The system im building from scratch is working perfectly booting in 
enforcing mode without devfsd. I am fine tuning the policy now.

Im having a problem with my X Window devpts entries.  The task sid when 
X Window creates a pty is xdm_t. What should the proper type be? Ssh 
works perfectly now in enforcing mode. X stops when I switch to 
enforcing mode. What are the type transitions when gdm starts X window?

>--
>Stephen D. Smalley, NAI Labs
>ssmalley@nai.com
>
>
>  
>




--
You have received this message because you are subscribed to the selinux 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: automatic type transitions for pts in devfs

[Stephen Smalley]

On Thu, 11 Jul 2002, Debian User wrote:

> Im having a problem with my X Window devpts entries.  The task sid when
> X Window creates a pty is xdm_t. What should the proper type be? Ssh
> works perfectly now in enforcing mode. X stops when I switch to
> enforcing mode. What are the type transitions when gdm starts X window?

To use an X Display Manager, you need a patched [xgk]dm to set the
security context for the user session, as noted in selinux/README.  We do
not provide a patched [xgk]dm, but I think Russell Coker has a patched kdm
and Mark Westerman has a patched gdm.  If you are using a patched [xgk]dm,
then the pty should be created by a process in the user's domain, not
xdm_t, so it should pick up the proper user_devpts_t or sysadm_devpts_t
type automatically.  At least, that has been my experience.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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.

dhcpc_t

[Simon Han]

Hi,
	It seems to me that normal user needs to have packet_socket
permission.  Of course, I can add directly to macros/user_mmacros.te, but
I would like to seek for advice before doing so since packet_socket is
relatively powerful.

The message is following,

Jul 11 10:25:26 dhcp2-200 kernel: avc:  denied  { recvfrom } for  pid=693
exe=/sbin/ypbind saddr=206.17.239.200 source=17664 daddr=206.17.239.33
dest=84 netif=eth0 scontext=system_u:system_r:dhcpc_t
tcontext=system_u:system_r:ypbind_t tclass=packet_socket

Jul 11 10:25:39 dhcp2-200 kernel: avc:  denied  { recvfrom } for  pid=1807
exe=/usr/bin/gnome-session saddr=206.17.239.200 source=17664
daddr=206.17.239.33 dest=116 netif=eth0 scontext=system_u:system_r:dhcpc_t
tcontext=simon:user_r:user_t tclass=packet_socket

Jul 11 10:26:16 dhcp2-200 kernel: avc:  denied  { recvfrom } for  pid=5833
exe=/usr/kerberos/bin/telnet saddr=206.17.239.200 source=17680
daddr=128.97.92.179 dest=53 netif=eth0 scontext=system_u:system_r:dhcpc_t
tcontext=simon:sysadm_r:sysadm_t tclass=packet_socket


Thanks in advance,
Simon


--
You have received this message because you are subscribed to the selinux 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: dhcpc_t

[Stephen Smalley]

On Thu, 11 Jul 2002, Simon Han wrote:

> 	It seems to me that normal user needs to have packet_socket
> permission.  Of course, I can add directly to macros/user_mmacros.te, but
> I would like to seek for advice before doing so since packet_socket is
> relatively powerful.

That wouldn't be a good idea, and it is not necessary for the audit
messages you showed.  In each message, the denial was caused when the
AF_PACKET socket created by dhcpcd received a packet from another domain.
Hence, at most, you would add a rule to dhcpc.te permitting dhcpcd to
receive packets from any domain (e.g. allow dhcpc_t domain:packet_socket
recvfrom;).  I'm not even sure whether this is necessary for the operation
of dhcpcd; you might be able to just use dontaudit to suppress these
messages and silently drop these packets from the dhcpcd socket.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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: dhcpc_t

[Ed Street]

Hello,

I can think of a few kiddie wacker toys that would/could make use of
that that allow.

Ed

=> -----Original Message-----
=> From: owner-selinux@tycho.nsa.gov
[mailto:owner-selinux@tycho.nsa.gov] On
=> Behalf Of Stephen Smalley
=> Sent: Thursday, July 11, 2002 2:32 PM
=> To: Simon Han
=> Cc: selinux@tycho.nsa.gov
=> Subject: Re: dhcpc_t
=> 
=> 
=> On Thu, 11 Jul 2002, Simon Han wrote:
=> 
=> > 	It seems to me that normal user needs to have packet_socket
=> > permission.  Of course, I can add directly to
macros/user_mmacros.te,
=> but
=> > I would like to seek for advice before doing so since packet_socket
is
=> > relatively powerful.
=> 
=> That wouldn't be a good idea, and it is not necessary for the audit
=> messages you showed.  In each message, the denial was caused when the
=> AF_PACKET socket created by dhcpcd received a packet from another
domain.
=> Hence, at most, you would add a rule to dhcpc.te permitting dhcpcd to
=> receive packets from any domain (e.g. allow dhcpc_t
domain:packet_socket
=> recvfrom;).  I'm not even sure whether this is necessary for the
=> operation
=> of dhcpcd; you might be able to just use dontaudit to suppress these
=> messages and silently drop these packets from the dhcpcd socket.
=> 
=> --
=> Stephen D. Smalley, NAI Labs
=> ssmalley@nai.com


--
You have received this message because you are subscribed to the selinux 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.