Bug 805544 - SELinux is preventing /usr/sbin/lxdm-binary from 'unlink' accesses on the file /var/log/lxdm.log.old.
Summary: SELinux is preventing /usr/sbin/lxdm-binary from 'unlink' accesses on the fil...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 17
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:85a02cbe6c1407c64878a0eff5a...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-21 14:48 UTC by Hicham HAOUARI
Modified: 2012-10-17 08:44 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-10-17 08:44:18 UTC
Type: ---


Attachments (Terms of Use)

Description Hicham HAOUARI 2012-03-21 14:48:09 UTC
libreport version: 2.0.8
executable:     /usr/bin/python
hashmarkername: setroubleshoot
kernel:         3.3.0-1.fc17.x86_64
reason:         SELinux is preventing /usr/sbin/lxdm-binary from 'unlink' accesses on the file /var/log/lxdm.log.old.
time:           Wed 21 Mar 2012 03:47:54 PM CET

description:
:SELinux is preventing /usr/sbin/lxdm-binary from 'unlink' accesses on the file /var/log/lxdm.log.old.
:
:*****  Plugin catchall (100. confidence) suggests  ***************************
:
:If you believe that lxdm-binary should be allowed unlink access on the lxdm.log.old 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 lxdm-binary /var/log/audit/audit.log | audit2allow -M mypol
:# semodule -i mypol.pp
:
:Additional Information:
:Source Context                system_u:system_r:xdm_t:s0-s0:c0.c1023
:Target Context                unconfined_u:object_r:var_log_t:s0
:Target Objects                /var/log/lxdm.log.old [ file ]
:Source                        lxdm-binary
:Source Path                   /usr/sbin/lxdm-binary
:Port                          <Unknown>
:Host                          (removed)
:Source RPM Packages           lxdm-0.4.1-1.fc17.x86_64
:Target RPM Packages           
:Policy RPM                    selinux-policy-3.10.0-104.fc17.noarch
:Selinux Enabled               True
:Policy Type                   targeted
:Enforcing Mode                Enforcing
:Host Name                     (removed)
:Platform                      Linux (removed) 3.3.0-1.fc17.x86_64 #1 SMP
:                              Mon Mar 19 03:03:39 UTC 2012 x86_64 x86_64
:Alert Count                   2
:First Seen                    Wed 21 Mar 2012 10:06:09 AM CET
:Last Seen                     Wed 21 Mar 2012 03:16:31 PM CET
:Local ID                      b03e56eb-1ba9-46e7-8be9-ded6f08f80c1
:
:Raw Audit Messages
:type=AVC msg=audit(1332339391.457:231): avc:  denied  { unlink } for  pid=3285 comm="lxdm-binary" name="lxdm.log.old" dev="sda2" ino=397302 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=file
:
:
:type=SYSCALL msg=audit(1332339391.457:231): arch=x86_64 syscall=unlink success=no exit=EACCES a0=409666 a1=7fffe6d857f8 a2=3 a3=7fffe6d853b0 items=0 ppid=1 pid=3285 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=lxdm-binary exe=/usr/sbin/lxdm-binary subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
:
:Hash: lxdm-binary,xdm_t,var_log_t,file,unlink
:
:audit2allowunable to open /sys/fs/selinux/policy:  Permission denied
:
:
:audit2allow -Runable to open /sys/fs/selinux/policy:  Permission denied
:
:

Comment 1 Daniel Walsh 2012-03-21 15:11:53 UTC
restorecon -R -v /var/log/lxdm.log*

Not sure how this got mislabled.

Comment 2 Ferdinand 2012-06-19 22:37:04 UTC
I got this selinux warning as well.
Running restorecon -R -v /var/log/lxdm.log* exits without any changes.

# ls -Z /var/log/lxdm.log*
-rw-r-----. root root system_u:object_r:xserver_log_t:s0 /var/log/lxdm.log
-rw-r-----. root root system_u:object_r:var_log_t:s0   /var/log/lxdm.log.old

I removed lxdm.log.old manually, and will check what happens next.

Comment 3 Daniel Walsh 2012-06-20 18:22:07 UTC
Fixed in selinux-policy-3.10.0-133.fc17

.old is mislabeled in policy.

Comment 4 Fedora Update System 2012-06-26 21:46:46 UTC
selinux-policy-3.10.0-134.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-134.fc17

Comment 5 Fedora Update System 2012-06-28 03:36:29 UTC
Package selinux-policy-3.10.0-134.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.10.0-134.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-10008/selinux-policy-3.10.0-134.fc17
then log in and leave karma (feedback).

Comment 6 Ferdinand 2012-06-29 17:07:54 UTC
Thanks. The policy now has them both as system_u:object_r:xserver_log_t:s0, which works. I'd like to note though that lxdm.log context is originally system_u:object_r:xdm_log_t:s0 when created. So that's what they'll both be a couple of boots after the policy update.

Comment 7 Fedora Update System 2012-06-30 21:50:31 UTC
selinux-policy-3.10.0-134.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 8 Miroslav Grepl 2012-07-02 07:14:19 UTC
So are you saying you see lxdm.log labeled as xdm_log_t?

Comment 9 Ferdinand 2012-07-02 21:25:09 UTC
Yes, I'm sorry if that was unclear.
Apparently xdm_t can remove xserver_log_t, so without restorecon running the context reverts to xdm_log_t.

This bug only appeared after file context was changed (by restorecon) from xdm_log_t to xserver_log_t and var_log_t respectively. I guess that happened after a policy update.

Comment 10 Miroslav Grepl 2012-07-03 09:22:01 UTC
You should not see var_log_t anymore.

Comment 11 Ferdinand 2012-07-03 22:10:46 UTC
That's right, I don't. I was referring to the original bug. It was technically fixed, but wouldn't it be best if the policy reflected reality? That would mean updating policy for /var/log/lxdm.log and /var/log/lxdm.log.old from xserver_log_t to xdm_log_t.

Current situation:

$ ls -Z /var/log/lxdm*
-rw-r-----. root root system_u:object_r:xdm_log_t:s0   /var/log/lxdm.log
-rw-r-----. root root system_u:object_r:xdm_log_t:s0   /var/log/lxdm.log.old

$ restorecon -nv /var/log/lxdm*
restorecon reset /var/log/lxdm.log context system_u:object_r:xdm_log_t:s0->system_u:object_r:xserver_log_t:s0
restorecon reset /var/log/lxdm.log.old context system_u:object_r:xdm_log_t:s0->system_u:object_r:xserver_log_t:s0

Comment 12 Miroslav Grepl 2012-07-04 13:45:28 UTC
Yes, this is a bug. We allow xdm_t to manage both types so it will work.


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