Bug 120213

The first problem is because the pty is relabeled for the
execution of the sudo command in the new role, while the grep is run
by the shell and stays in the old role and domain.  Allowing staff_t
to rw sysadm_devpts_t defeats the purpose of having a separate devpts
type for sysadm.  Alternative is to _not_ relabel the tty/pty in sudo,
due to its specialized nature for executing a single command rather
than creating a new shell (unlike su or newrole).   But this may
require allowing various program domains that are normally only run
from sysadm_t to access staff_devpts_t.

The second problem is because the shell opens the file and passes the
descriptor directly to sudo, so that sudo directly needs write
permission to the file, vs. a model where the shell would interpose
itself on such writes.   Simplest solution would be to macro-ize the
sudo domain and instantiate a per-userdomain $1_sudo_t domain that
also includes permissions to $1_tmp_t, $1_home_t, etc, so that when
staff_t runs sudo, it can write to staff tmp files or staff home files
and when sysadm_t run sudo, it can write to sysadm tmp files or sysadm
home files, etc.  A more fundamental change (requiring change to
SELinux kernel code) would be to introduce distinct permissions for
directly opening a file vs. inheriting and using a descriptor to a
file from another process, so that the policy can say "sudo can write
to anything it inherits from the caller, but cannot directly open
anything for writing itself."  But that isn't really in line with the
goals of MAC, where you want to control the actual data flow, not just
how you managed to get access in the first place.

It seems to me that the "idealogically correct" (but far from
simplest) way of fixing would be to modify sudo to do the following
when SELinux is enabled:
- Create a fresh pty with the SELinux context appropriate for the
target role/user;
- Leave the context of the original tty intact;
- Start the sesh process attached to the _new_ tty;
- Stay "actively involved", "manually" copying all the data between
the new pty and the original stdin/stdout/stderr.

This IMHO has several advantages:
- avoids all problems related to relabeling of the tty that is already
in use (e.g. could be in use by background processes, etc).
- avoids creating any holes on policies - the bariier between data
belonging to different roles is completely intact - data is still not
allowed to flow where it is not supposed to, except for what sudo
_explicitly_ copies between the two security domains, and sudo, of
course, can do all kinds of permission checks before allowing that to
happen.

Fixed in current policy.  I am not relabeling the terminals since this
caused more problems than it solved.  Eventually we may have an more
elagant solution.  sudo will now write to the /tmp and home dirs.

Dan

With policy-sources-1.11.2-18 and sudo-1.6.7p5-26 I am now seeing
things like:

audit(1083015583.044:0): avc:  denied  { read write } for  pid=14826
exe=/usr/sbin/load_policy path=/dev/pts/14 dev= ino=16
scontext=aleksey:sysadm_r:load_policy_t
tcontext=aleksey:object_r:staff_devpts_t tclass=chr_file
audit(1083015710.498:0): avc:  denied  { write } for  pid=14862
exe=/usr/bin/slocate path=pipe:[2781289] dev= ino=2781289
scontext=aleksey:system_r:locate_t tcontext=aleksey:staff_r:staff_t
tclass=fifo_file
audit(1083015721.249:0): avc:  denied  { write } for  pid=14870
exe=/usr/bin/slocate path=/tmp/out dev=hda2 ino=212625
scontext=aleksey:system_r:locate_t
tcontext=aleksey:object_r:staff_tmp_t tclass=file

Here are my local mods to fix some of these:

allow { checkpolicy_t load_policy_t sysadm_mail_t}
staff_devpts_t:chr_file { getattr read write };
allow { locate_t sysadm_mail_t} staff_tmp_t:file { getattr write };

Update: my local mods currently include 

allow { checkpolicy_t consoletype_t ifconfig_t iptables_t ntpd_t
load_policy_t sysadm_mail_t ping_t traceroute_t mount_t lvm_t
bootloader_t ldconfig_t squid_t } { staff_devpts_t staff_tty_device_t
}:chr_file { getattr read write ioctl };
allow { locate_t sysadm_mail_t } staff_tmp_t:file { getattr write };

Simpler option in the absence of doing what Aleksey suggests in #2
is to change admin_tty_type definition in domains/admin.te to
{ ptyfile ttyfile }, so that all administrative programs that are
already authorized to access sysadm tty/pty's will also be able to
access staff and user tty/pty's.

Fixed in current release