Bug 119209 - locate, setfiles and tcpdump are unable to write output to staff terminal
Summary: locate, setfiles and tcpdump are unable to write output to staff terminal
Alias: None
Product: Fedora
Classification: Fedora
Component: sudo   
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Colin Walters
QA Contact: Ben Levenson
Keywords: SELinux
Depends On:
TreeView+ depends on / blocked
Reported: 2004-03-26 13:33 UTC by Aleksey Nogin
Modified: 2007-11-30 22:10 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-03-31 21:21:07 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
sesh.c patch (1.20 KB, patch)
2004-03-31 17:29 UTC, Colin Walters
no flags Details | Diff
fix sudo signal handling (1017 bytes, text/plain)
2004-03-31 19:10 UTC, Colin Walters
no flags Details

Description Aleksey Nogin 2004-03-26 13:33:37 UTC
If I run setfiles from staff_r using sudo, then it ends up being
uncapable of reporting what it does to my terminal:

audit(1080307491.935:0): avc:  denied  { write } for  pid=7248
exe=/usr/sbin/setfiles path=/dev/pts/9 dev= ino=11
tcontext=aleksey:object_r:staff_devpts_t tclass=chr_file

Should this be allowed?

I am currently using policy-sources-1.9-15

Comment 1 Colin Walters 2004-03-26 22:04:37 UTC
What role were you in when running setfiles?  staff_r? If so you
should be sysadm_r.

Comment 2 Aleksey Nogin 2004-03-26 22:39:11 UTC
I was logged in as staff_r and I ran "sudo -r sysadm_r
/usr/sbin/setfiles ...". IMHO this should be allowed.

Comment 3 Aleksey Nogin 2004-03-28 01:03:55 UTC
There is an identical problem with tcpdump:

Mar 27 16:47:39 dell kernel: audit(1080434859.550:0): avc:  denied  {
write } for  pid=2240 exe=/usr/sbin/tcpdump path=/dev/pts/1 dev= ino=3
tcontext=aleksey:object_r:staff_devpts_t tclass=chr_file

Is there some way in SELinux framework to give program write access to
their current tty w/o giving them write access to arbitrary terminals?

Comment 4 Aleksey Nogin 2004-03-29 10:43:22 UTC
Yet another:

audit(1080556614.496:0): avc:  denied  { write } for  pid=3628
exe=/usr/bin/slocate path=/dev/pts/6 dev= ino=8
tcontext=aleksey:object_r:staff_devpts_t tclass=chr_file

Comment 5 Aleksey Nogin 2004-03-29 10:45:55 UTC
Oh, and a slightly different problem in the "processes that run under
sudo are not allowed to talk back" category:

audit(1080556814.719:0): avc:  denied  { sigchld } for  pid=3669
exe=/usr/bin/sudo scontext=aleksey:sysadm_r:setfiles_t
tcontext=aleksey:staff_r:sudo_t tclass=process
audit(1080556612.324:0): avc:  denied  { sigchld } for  pid=3618
exe=/usr/bin/sudo scontext=aleksey:system_r:locate_t
tcontext=aleksey:staff_r:sudo_t tclass=process

Comment 6 Aleksey Nogin 2004-03-29 21:52:47 UTC
Stephen Smalley wrote (in the mailing list):

> [...] in this particular case, where sudo is performing an explicit
> role change, I would expect that sudo would relabel the pty based on
> the new user domain, so it should be relabeled to sysadm_devpts_t
> while the command is being executed, and then reset to its original
> type.

Comment 7 Stephen Smalley 2004-03-30 13:17:41 UTC
$ getfilecon `tty`
/dev/pts/9      sds:object_r:staff_devpts_t
$ sudo getfilecon `tty`
/dev/pts/9      sds:object_r:sysadm_devpts_t
$ getfilecon `tty`
/dev/pts/9      sds:object_r:staff_devpts_t

sudo appears to be relabeling the pty correctly, as shown by the
above sequence.  sudo fixfiles relabel also seems to function
as expected.  

Comment 8 Aleksey Nogin 2004-03-30 15:58:56 UTC
Hm, I also see the same behavior as described in comment #7 - sudo
does relabel the terminal. But why do I get those write AVCs? Could
the sigchld AVCs have something to do with this?

Comment 9 Stephen Smalley 2004-03-30 16:02:37 UTC
Is the command being run in the background?  If so, then perhaps the
following is happening:
sudo relabels terminal to new type, starts command via sesh, command
is backgrounded, sesh exits, sudo relabels terminal to old type,
command continues to run and tries to access terminal, access is no
longer granted, command process dies, sudo tries to directly reap
since sesh is  already gone.

Comment 10 Aleksey Nogin 2004-03-30 16:16:18 UTC
Ah, interesting! If I add

allow locate_t sudo_t:process { sigchld };
allow netutils_t sudo_t:process { sigchld };
allow setfiles_t sudo_t:process { sigchld };

then the processes run in the foreground and everything is well and
good. But if sigchld is prohibited, then the processes end up running
in the background and often (not always - weird) would not have write
permissions to the terminal.

Comment 11 Stephen Smalley 2004-03-30 16:30:21 UTC
sesh should fork and exec the command in the child, and have the
parent wait on it.  At present, sesh just overlays itself with the
command, so we end up with sudo having to directly reap all program
domains.  If sesh handles the reaping itself, then the usual rules
allowing the user domains to reap the program domains will cover it.

Comment 12 Aleksey Nogin 2004-03-30 16:48:48 UTC
Per comment #11 this seems like a sudo problem, not a policy one.

Comment 13 Colin Walters 2004-03-30 19:12:20 UTC
I'll take care of this bug, if there are no objections.

Comment 14 Colin Walters 2004-03-30 20:02:47 UTC
The current policy has:
allow domain sudo_t:process sigchld;

This seems like it would cover this issue?

Comment 15 Stephen Smalley 2004-03-31 13:12:57 UTC
At the cost of generating an extra access vector per domain in the
policy.  Better to fix sesh to fork and exec the command in the child,
and have the parent reap it, so that the existing rules for reaping of
the program domains by the user domains will cover it.

Comment 16 Colin Walters 2004-03-31 17:15:43 UTC
Right, that makes sense.  I guess Aleksey must be using an older policy.
Anyways, I should have a patch soon...

Comment 17 Colin Walters 2004-03-31 17:29:26 UTC
Created attachment 99012 [details]
sesh.c patch

Comment 18 Colin Walters 2004-03-31 17:36:17 UTC
I am getting weird behavior though when running tcpdump; if I
Control-C it, I get lots of ioctl and write denials on the tty, and
then I get logged out.  Is anyone else seeing this?  

[time passes]

Ah, I think I see the problem.  sudo.c is restoring the default SIGINT
handler before exec, but with the SELinux patch, it now does a
fork+exec.  So the SIGINT is reaching sudo, and killing it.

I'll create a patch for this soon.

Comment 19 Colin Walters 2004-03-31 19:10:09 UTC
Created attachment 99013 [details]
fix sudo signal handling

This only restores the signal handlers before the exec.

Comment 20 Colin Walters 2004-03-31 20:36:12 UTC
Oh and just so we remember - we also need to delete the 
allow domain sudo_t:process sigchld;
inside sudo.te.

Comment 21 Colin Walters 2004-03-31 21:21:07 UTC
Ok, sudo-1.67p5-24 uploaded.

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