Bug 120213 - No way to capture sudo output
No way to capture sudo output
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: sudo (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
: SELinux
Depends On:
Blocks: FC2Target
  Show dependency treegraph
 
Reported: 2004-04-06 16:49 EDT by Aleksey Nogin
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-09 13:55:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Aleksey Nogin 2004-04-06 16:49:22 EDT
With the current policy, there does not see to be a way to capture
sudo's output.

% sudo ls -Z /dev | grep aleksey
% dmesg|tail
audit(1081284530.103:0): avc:  denied  { write } for  pid=3235
exe=/bin/grep path=/dev/pts/5 dev= ino=7
scontext=aleksey:staff_r:staff_t
tcontext=aleksey:object_r:sysadm_devpts_t tclass=chr_file
audit(1081284530.103:0): avc:  denied  { write } for  pid=3235
exe=/bin/grep path=/dev/pts/5 dev= ino=7
scontext=aleksey:staff_r:staff_t
tcontext=aleksey:object_r:sysadm_devpts_t tclass=chr_file
audit(1081284530.103:0): avc:  denied  { write } for  pid=3235
exe=/bin/grep path=/dev/pts/5 dev= ino=7
scontext=aleksey:staff_r:staff_t
tcontext=aleksey:object_r:sysadm_devpts_t tclass=chr_file
audit(1081284530.103:0): avc:  denied  { write } for  pid=3235
exe=/bin/grep path=/dev/pts/5 dev= ino=7
scontext=aleksey:staff_r:staff_t
tcontext=aleksey:object_r:sysadm_devpts_t tclass=chr_file
audit(1081284530.103:0): avc:  denied  { write } for  pid=3235
exe=/bin/grep path=/dev/pts/5 dev= ino=7
scontext=aleksey:staff_r:staff_t
tcontext=aleksey:object_r:sysadm_devpts_t tclass=chr_file
audit(1081284530.103:0): avc:  denied  { write } for  pid=3235
exe=/bin/grep path=/dev/pts/5 dev= ino=7
scontext=aleksey:staff_r:staff_t
tcontext=aleksey:object_r:sysadm_devpts_t tclass=chr_file
audit(1081284530.103:0): avc:  denied  { write } for  pid=3235
exe=/bin/grep path=/dev/pts/5 dev= ino=7
scontext=aleksey:staff_r:staff_t
tcontext=aleksey:object_r:sysadm_devpts_t tclass=chr_file
audit(1081284530.103:0): avc:  denied  { write } for  pid=3235
exe=/bin/grep path=/dev/pts/5 dev= ino=7
scontext=aleksey:staff_r:staff_t
tcontext=aleksey:object_r:sysadm_devpts_t tclass=chr_file
audit(1081284530.103:0): avc:  denied  { write } for  pid=3235
exe=/bin/grep path=/dev/pts/5 dev= ino=7
scontext=aleksey:staff_r:staff_t
tcontext=aleksey:object_r:sysadm_devpts_t tclass=chr_file
audit(1081284530.103:0): avc:  denied  { write } for  pid=3235
exe=/bin/grep path=/dev/pts/5 dev= ino=7
scontext=aleksey:staff_r:staff_t
tcontext=aleksey:object_r:sysadm_devpts_t tclass=chr_file
% sudo ls -Z /dev > /tmp/abcd
% ls -l /tmp/abcd
-rw-r--r--  1 aleksey aleksey 0 Apr  6 13:49 /tmp/abcd
% dmesg | tail -1
audit(1081284549.807:0): avc:  denied  { write } for  pid=3242
exe=/usr/bin/sudo path=/tmp/abcd dev=hda2 ino=345579
scontext=aleksey:staff_r:sudo_t tcontext=aleksey:object_r:staff_tmp_t
tclass=file
Comment 1 Stephen Smalley 2004-04-08 08:04:42 EDT
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.
Comment 2 Aleksey Nogin 2004-04-08 20:50:40 EDT
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.
Comment 3 Daniel Walsh 2004-04-22 14:56:45 EDT
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
Comment 4 Aleksey Nogin 2004-04-26 17:38:36 EDT
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
Comment 5 Aleksey Nogin 2004-04-28 03:05:47 EDT
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 };

Comment 6 Aleksey Nogin 2004-05-10 16:16:05 EDT
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 };
Comment 7 Stephen Smalley 2004-07-08 15:29:58 EDT
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.
Comment 8 Daniel Walsh 2005-02-09 13:55:05 EST
Fixed in current release

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