/dev/pts/x use denials

/dev/pts/x use denials

[Ivan Gyurdiev]

Strange denials:

/dev/pts/2 has context: sysadm_tmp_t.
Those happen intermittently, but I can't figure out when exactly.
I am logged in as a regular user, but su-ed to root. Usually accompanied
by a dac_override.

audit(1112568847.907:0): avc:  denied  { use } for  pid=22851
exe=/usr/bin/mplayer path=/dev/pts/2 dev=devpts ino=4
scontext=root:sysadm_r:sysadm_mplayer_t tcontext=phantom:staff_r:staff_t
tclass=fd
audit(1112568874.222:0): avc:  denied  { use } for  pid=22870
exe=/usr/bin/tvtime path=/dev/pts/2 dev=devpts ino=4
scontext=root:sysadm_r:sysadm_tvtime_t tcontext=phantom:staff_r:staff_t
tclass=fd
audit(1112568881.428:0): avc:  denied  { use } for  pid=22872
exe=/bin/bash path=/dev/pts/2 dev=devpts ino=4
scontext=root:sysadm_r:sysadm_mozilla_t tcontext=phantom:staff_r:staff_t
tclass=fd

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: /dev/pts/x use denials

[Ivan Gyurdiev]

On Sun, 2005-04-03 at 19:00 -0400, Ivan Gyurdiev wrote: 
> Strange denials:
> 
> /dev/pts/2 has context: sysadm_tmp_t.
> Those happen intermittently, but I can't figure out when exactly.
> I am logged in as a regular user, but su-ed to root. Usually accompanied
> by a dac_override.

It's sometimes followed by a dac_override - not all the time.
Here's something reproducible:

If I su to root, launch tvtime/mplayer/whatever, then make load
the selinux policy, I get use denial on /dev/pts. Then if I launch
the same program - no use denial. Then I make load the policy again,
launch program, and I get a use denial.

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: /dev/pts/x use denials

[Daniel J Walsh]

Ivan Gyurdiev wrote:

>On Sun, 2005-04-03 at 19:00 -0400, Ivan Gyurdiev wrote: 
>  
>
>>Strange denials:
>>
>>/dev/pts/2 has context: sysadm_tmp_t.
>>Those happen intermittently, but I can't figure out when exactly.
>>I am logged in as a regular user, but su-ed to root. Usually accompanied
>>by a dac_override.
>>    
>>
>
>It's sometimes followed by a dac_override - not all the time.
>Here's something reproducible:
>
>If I su to root, launch tvtime/mplayer/whatever, then make load
>the selinux policy, I get use denial on /dev/pts. Then if I launch
>the same program - no use denial. Then I make load the policy again,
>launch program, and I get a use denial.
>
>  
>
If you are running in permissive mode, you only get the denial once.  
When you
reload the policy it clears the flag.

Dan

-- 



--
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: /dev/pts/x use denials

[Stephen Smalley]

On Sun, 2005-04-03 at 19:00 -0400, Ivan Gyurdiev wrote:
> Strange denials:
> 
> /dev/pts/2 has context: sysadm_tmp_t.
> Those happen intermittently, but I can't figure out when exactly.
> I am logged in as a regular user, but su-ed to root. Usually accompanied
> by a dac_override.
> 
> audit(1112568847.907:0): avc:  denied  { use } for  pid=22851
> exe=/usr/bin/mplayer path=/dev/pts/2 dev=devpts ino=4
> scontext=root:sysadm_r:sysadm_mplayer_t tcontext=phantom:staff_r:staff_t
> tclass=fd
> audit(1112568874.222:0): avc:  denied  { use } for  pid=22870
> exe=/usr/bin/tvtime path=/dev/pts/2 dev=devpts ino=4
> scontext=root:sysadm_r:sysadm_tvtime_t tcontext=phantom:staff_r:staff_t
> tclass=fd
> audit(1112568881.428:0): avc:  denied  { use } for  pid=22872
> exe=/bin/bash path=/dev/pts/2 dev=devpts ino=4
> scontext=root:sysadm_r:sysadm_mozilla_t tcontext=phantom:staff_r:staff_t
> tclass=fd

I don't see sysadm_tmp_t anywhere above. I do see staff_t fd's, but that
just shows that the descriptor was opened by a staff_t process and then
inherited across the su, nothing surprising there.  Earlier versions of
pam_selinux did try closing and re-opening descriptors 0-2 as newrole
does, but that proved problematic.  su likely just needs to be directly
patched rather than using pam_selinux.

-- 
Stephen Smalley <sds@tycho.nsa.gov>
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: /dev/pts/x use denials

[Ivan Gyurdiev]

> I don't see sysadm_tmp_t anywhere above. 

Right, that was a typo.. I'm sure I meant sysadm_devpts_t 
(or at least I hope I did - sysadm_tmp_t doesn't make sense)

> I do see staff_t fd's, but that
> just shows that the descriptor was opened by a staff_t process and then
> inherited across the su, nothing surprising there.  Earlier versions of
> pam_selinux did try closing and re-opening descriptors 0-2 as newrole
> does, but that proved problematic.  su likely just needs to be directly
> patched rather than using pam_selinux.

What was the problem?
I remember another message about this, but I didn't understand it then -
I see what you mean now.

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: /dev/pts/x use denials

[Stephen Smalley]

On Mon, 2005-04-04 at 11:43 -0400, Ivan Gyurdiev wrote:
> > I do see staff_t fd's, but that
> > just shows that the descriptor was opened by a staff_t process and then
> > inherited across the su, nothing surprising there.  Earlier versions of
> > pam_selinux did try closing and re-opening descriptors 0-2 as newrole
> > does, but that proved problematic.  su likely just needs to be directly
> > patched rather than using pam_selinux.
> 
> What was the problem?
> I remember another message about this, but I didn't understand it then -
> I see what you mean now.

IIRC, it had to do with su's manipulation of fsuid/fsguid prior to
calling pam_open_session; this ultimately prevented pam_selinux from
being able to re-open the tty due to DAC restrictions.  There were
several bugzillas related to su and sudo and the issues of tty
relabeling, descriptor inheritance, etc during earlier Fedora
integration (likely filed against rawhide).  As a separate but related
issue, having a proxy pty for su/sudo similar to what is now being done
for run_init would be helpful in providing stronger isolation.  That
came up too during earlier bugzillas I think.

-- 
Stephen Smalley <sds@tycho.nsa.gov>
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: /dev/pts/x use denials

[Daniel J Walsh]

Ivan Gyurdiev wrote:

>>I don't see sysadm_tmp_t anywhere above. 
>>    
>>
>
>Right, that was a typo.. I'm sure I meant sysadm_devpts_t 
>(or at least I hope I did - sysadm_tmp_t doesn't make sense)
>
>  
>
>>I do see staff_t fd's, but that
>>just shows that the descriptor was opened by a staff_t process and then
>>inherited across the su, nothing surprising there.  Earlier versions of
>>pam_selinux did try closing and re-opening descriptors 0-2 as newrole
>>does, but that proved problematic.  su likely just needs to be directly
>>patched rather than using pam_selinux.
>>    
>>
>
>What was the problem?
>I remember another message about this, but I didn't understand it then -
>I see what you mean now.
>
>  
>
Closing and reopeing a tty device in a pam module is not a good idea.

-- 



--
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.