Bug 119209

What role were you in when running setfiles?  staff_r? If so you
should be sysadm_r.

I was logged in as staff_r and I ran "sudo -r sysadm_r
/usr/sbin/setfiles ...". IMHO this should be allowed.

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
scontext=aleksey:sysadm_r:netutils_t
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?

Yet another:

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

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

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.

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

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?

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.

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.

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.

Per comment #11 this seems like a sudo problem, not a policy one.

I'll take care of this bug, if there are no objections.

The current policy has:
allow domain sudo_t:process sigchld;

This seems like it would cover this issue?

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.

Right, that makes sense.  I guess Aleksey must be using an older policy.
Anyways, I should have a patch soon...

Created attachment 99012 [details]
sesh.c patch

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.

Created attachment 99013 [details]
fix sudo signal handling

This only restores the signal handlers before the exec.

Oh and just so we remember - we also need to delete the 
allow domain sudo_t:process sigchld;
inside sudo.te.

Ok, sudo-1.67p5-24 uploaded.