Bug 743885 - SELinux is preventing /lib/systemd/systemd-logind from 'unlink' accesses on the file user.
Summary: SELinux is preventing /lib/systemd/systemd-logind from 'unlink' accesses on t...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 16
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:c69158a0043008dc8065e43c559...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-10-06 11:46 UTC by Antonio A. Olivares
Modified: 2011-10-10 14:35 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-10 12:00:53 UTC
Type: ---


Attachments (Terms of Use)

Description Antonio A. Olivares 2011-10-06 11:46:28 UTC
libreport version: 2.0.6
executable:     /usr/bin/python
hashmarkername: setroubleshoot
kernel:         3.1.0-0.rc8.git0.1.fc16.x86_64
reason:         SELinux is preventing /lib/systemd/systemd-logind from 'unlink' accesses on the file user.
time:           Thu Oct  6 06:45:51 2011

description:
:SELinux is preventing /lib/systemd/systemd-logind from 'unlink' accesses on the file user.
:
:*****  Plugin catchall (100. confidence) suggests  ***************************
:
:If you believe that systemd-logind should be allowed unlink access on the user file by default.
:Then you should report this as a bug.
:You can generate a local policy module to allow this access.
:Do
:allow this access for now by executing:
:# grep systemd-logind /var/log/audit/audit.log | audit2allow -M mypol
:# semodule -i mypol.pp
:
:Additional Information:
:Source Context                system_u:system_r:systemd_logind_t:s0
:Target Context                system_u:object_r:config_home_t:s0
:Target Objects                user [ file ]
:Source                        systemd-logind
:Source Path                   /lib/systemd/systemd-logind
:Port                          <Unknown>
:Host                          (removed)
:Source RPM Packages           systemd-36-3.fc16
:Target RPM Packages           
:Policy RPM                    selinux-policy-3.10.0-36.fc16
:Selinux Enabled               True
:Policy Type                   targeted
:Enforcing Mode                Enforcing
:Host Name                     (removed)
:Platform                      Linux (removed)
:                              3.1.0-0.rc6.git0.3.fc16.x86_64 #1 SMP Fri Sep 16
:                              12:26:22 UTC 2011 x86_64 x86_64
:Alert Count                   1
:First Seen                    Wed 05 Oct 2011 08:21:19 PM CDT
:Last Seen                     Wed 05 Oct 2011 08:21:19 PM CDT
:Local ID                      fd9cfb45-4341-41e4-b6bc-4a11ebce6ec0
:
:Raw Audit Messages
:type=AVC msg=audit(1317864079.225:122): avc:  denied  { unlink } for  pid=5437 comm="systemd-logind" name="user" dev=tmpfs ino=21736 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:config_home_t:s0 tclass=file
:
:
:type=SYSCALL msg=audit(1317864079.225:122): arch=x86_64 syscall=unlinkat success=yes exit=0 a0=d a1=7fff1a6a6bd3 a2=0 a3=7fff1a6a6890 items=0 ppid=1 pid=5437 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=systemd-logind exe=/lib/systemd/systemd-logind subj=system_u:system_r:systemd_logind_t:s0 key=(null)
:
:Hash: systemd-logind,systemd_logind_t,config_home_t,file,unlink
:
:audit2allow
:
:#============= systemd_logind_t ==============
:allow systemd_logind_t config_home_t:file unlink;
:
:audit2allow -R
:
:#============= systemd_logind_t ==============
:allow systemd_logind_t config_home_t:file unlink;
:

Comment 1 Miroslav Grepl 2011-10-06 12:39:54 UTC
Fixed in selinux-policy-3.10.0-38.fc16

yum update --enablerepo=update-testing selinux-policy

Comment 2 Flóki Pálsson 2011-10-09 13:51:05 UTC
Shuold update-testing be updates-testing 
Is  selinux-policy-3.10.0-38.fc16 in updates-testing

Comment 3 Miroslav Grepl 2011-10-10 12:00:53 UTC
Yes, you are right. But this release should be now available from stable.

# yum update

Comment 4 Dominick Grift 2011-10-10 12:25:45 UTC
This is an issue that we need to tackle.

Currently we have a spec in userdomain.fc for the labelling of /run/user as user_tmp_t.

This is as far as i am concerned a temporary workaround because:

1. in policy nothing actually creates it
2. nothing owns /run/user either

I suspect that systemd creates this location since it also deletes it (as demonstrated by avc denial above)

/run/user/USER is "runtime home content" as per XDG specs.

So let us assume that logind creates/manages /run/user(/.*)? (we need to confirm this)

then we should probably allow logind to create this with a special type ( i am not sure whether systemd_logind_var_run_t would be suffice.

Then we should probably allow logind to type transition to "runtime_home_t" for all dirs below /run/user/:

/run/user/USER(/.*)? gen_context(system_u:object_r:runtime_home_t,s0)

users need to be able to manage content in /run/user/USER i believe.


http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

$ echo $XDG_RUNTIME_DIR
/run/user/dominick

Comment 5 Dominick Grift 2011-10-10 12:35:02 UTC
<grift> hi, does logind create/manages /run/user? i have not been able to determine what creates /run/user
 i know logind deletes it
<> logind-user.c:        r = safe_mkdir("/run/user", 0755, 0, 0);
<grift> thanks
 and do you also know what creates the user dirs below it?
 it cant be users themselves can it?
 since they arent allowed to add dir entries to /run/user
<> logind also:
 logind-user.c:                p = strappend("/run/user/", u->name)
 and there is mkdir below

Comment 6 Dominick Grift 2011-10-10 12:50:03 UTC
example:

type systemd_logind_user_t;
files_type(systemd_logind_user_t)

type runtime_home_t;
userdom_user_home_content(runtime_home_t)

manage_dirs_pattern(systemd_logind_t, { runtime_home_t systemd_logind_user_t }, { runtime_home_t systemd_logind_user_t })
filetrans_pattern(systemd_logind_t, var_run_t, systemd_logind_user_t, dir, "user")
filetrans_pattern(systemd_logind_t, systemd_logind_user_t, runtime_home_t, dir)

/run/user -d gen_context(system_u:object_r:systemd_logind_user_t,s0)
/run/user/USER(/.*)? gen_context(system_u:object_r:runtime_home_t,s0) # not sure if "USER" works here since xdm also has a dir there and i think thats a system user actually

Comment 7 Miroslav Grepl 2011-10-10 14:35:12 UTC
Well, I wouldn't say workaround. We found a solution which works. 

I understand your points and let's look about better solution if exists. Were you trying your example?


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