Red Hat Bugzilla – Bug 119533
konsole sessions not recorded in utmp
Last modified: 2007-11-30 17:10:39 EST
It I start konsole, then "w" would show me that session. In enforcing mode neither recording the session, not reading it (e.g. if I start the konsole in the permissive mode and then try running "w" in enforcing one) works. However I do not get anything in the logs (neither in enforcing mode nor in permissive one)... I am running as staff_r and the full list of uncommented entries in my tunable.te is given below: define(`readhome') define(`unrestricted_admin') define(`allow_user_tcp_server') define(`allow_user_dmesg') define(`ftpd_is_daemon') define(`direct_sysadm_daemon') define(`nscd_all_connect') define(`unlimitedServices')
# 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