Bug 119533

# Some shells ask for w access to utmp, but will operate
# correctly without it.  Do not audit write denials to utmp.
dontaudit $1_t initrc_var_run_t:file { getattr read write };

Looks like it is by design.   I will forward this bug to the NSA and
get their comments.

Dan

IIRC, the library functions for accessing utmp (e.g. getutent) always
try to open utmp read-write, and then fallback to opening it read-only
if that fails.  So you can't necessarily assume that an audit message
that shows a read/write denial actually means that write access was
required for application to function (in many cases, the application
just wanted to read an entry).

In the case of kconsole, if it is normally allowed to update utmp,
then it is reasonable to put it into a domain that can write to it, as
has been done for other programs like utempter.  But you don't want to
directly allow the user domains to write to utmp, for obvious reasons.

Added Russell to the CC list, as this is a policy issue.

Fixed policy to allow w to work.  Not going to fix writing to wtmp
file for now.

w still does not work:

% w
 18:51:27 up 1 day,  6:18,  0 users,  load average: 0.31, 0.49, 0.34
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
% sudo w
 18:51:32 up 1 day,  6:19,  1 user,  load average: 0.29, 0.48, 0.33
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
aleksey  pts/12   xxxxxxxxxxxxxxxxx 18:48    0.00s  0.15s  0.03s sshd:
aleksey [priv]
% rpm -q policy-sources
policy-sources-1.9.2-12
% dmesg|tail -1
audit(1081389087.528:0): avc:  denied  { lock } for  pid=10752
exe=/usr/bin/w path=/var/run/utmp dev=hda2 ino=179875
scontext=aleksey:staff_r:staff_t
tcontext=system_u:object_r:initrc_var_run_t tclass=file

Add 'lock' to the existing allow $1_t initrc_var_run_t:file { getattr
read }; rule in user_macros.te.  This should allow read-locking of the
file.

Fixed in policy-1.10.1-4

w still does not work. Strace shows

open("/var/run/utmp", O_RDWR)           = -1 EACCES (Permission denied)
open("/var/run/utmp", O_RDWR)           = -1 EACCES (Permission denied)

w shouldn't require write access to utmp, and even if we allowed it in
the policy, the Linux DAC permissions would prevent it.  It does
require read access, and that is allowed by the current policy.  The
library functions attempt to open rw initially, but fall back to
rdonly if that fails.  If I do a strace w, then I see the O_RDWR fail,
but it then proceeds to open O_RDONLY, and that succeeds.  However,
you are correct that w doesn't display any entries from user_t, and
I'm not sure why.  Possibly w doesn't gracefully handle the fact that
are denying access to the /proc/pid entries for other domains?  That's
the only difference I see.  But it can read the /proc/pid entries for
the same domain, so it should be able to get the information it needs.

Fixed in Rawhide