colord and xrdp clients

General support questions
Post Reply
Rocketrrt
Posts: 51
Joined: 2016/09/15 16:51:31

colord and xrdp clients

Post by Rocketrrt » 2016/09/15 17:58:57

Hi,

I am running CentOS 7.2 as Terminal Server. I am using XRDP for remote users. I am getting an SELinux Error on colord. SELinux is preventing /usr/libexec/colord from open access on the file /proc/<pid>/cmdline. I have run the Following commands

# grep colord /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

This does not fix the problem. From another site I added a policy for this in /etc/polkit-1/localauthoriy/50-local named allow-colord.pkla

It has the following in it:

[Allow colord for all users]
Identity=unix-user:*
Action=org.freedesktop.color-manager.create-device;org.freedesktop.color-manager.create-profile;org.freedesktop.color-manager.delete-device;org.freedesktop.color-manager.delete-profile;org.freedesktop.color-manager.modify-profile;freedesktop.color-manager.modify-profile
ResultAny=yes
ResultInactive=auth_admin
ResultActive=yes

This stops it from asking asking for the root password on connection, but still causes an SELinux Alert. Does anybody know a way so SELinux will not cause an alert. I would like colord to work or be ignored for all the users and keep SELinux on.

This was not a problem on CentOS 6.4 through 6.8 (which I am running today as Terminal Server now). We looking to migrate to CentOS 7.

Any help on this would be greatly appreciated

Thank you,

Ron

User avatar
TrevorH
Site Admin
Posts: 33202
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: colord and xrdp clients

Post by TrevorH » 2016/09/15 18:01:25

To use the audit log to create your own policy you need to run the command that has the problem and do so with selinux in permissive mode - setenforce 0 or you'll fix one denial and then promptly get hit by the next (repeat). When done, either setenforce 1 to put it back or reboot.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

Rocketrrt
Posts: 51
Joined: 2016/09/15 16:51:31

Re: colord and xrdp clients

Post by Rocketrrt » 2016/09/15 19:03:43

Hi,

I am not trying to use the audit log to create my own policy. I set the policy in /etc/polkit-1/localauthoriy/50-local named allow-colord.pkla I am already in permissive mode, the command I used and response:
sudo getenforce
Permissive

I already changed it in /etc/selinux/config setting SELINUX=permissive

I am thinking of turning off SELinux, but really don't want to that. People are using a gui front end (Gnome) and I don't want the alert message to come up. It does not seem to cause any problems but it is extremely annoying. I would like to either get the colord working on remote connections or a least not have the SELiunx message to come up.

Ron

User avatar
TrevorH
Site Admin
Posts: 33202
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: colord and xrdp clients

Post by TrevorH » 2016/09/15 23:57:20

If it's not working in permissive mode then it's not an selinux problem.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

Rocketrrt
Posts: 51
Joined: 2016/09/15 16:51:31

Re: colord and xrdp clients

Post by Rocketrrt » 2016/09/19 15:16:05

Hi,

Actually selinux is throwing the error, but the problem could be colord. This is the error being thrown is below.

But I think I might have it solved. If I run the suggestion below as sudo it does not work, but if run it as root then this seems to work. I still have more testing to do on it and I need to figure out the policy it is creating so I can add it so it runs on boot - restart.

Thanks,

Ron

SELinux is preventing /usr/libexec/colord from getattr access on the file /proc/<pid>/cgroup.

***** Plugin catchall (100. confidence) suggests **************************

If you believe that colord should be allowed getattr access on the cgroup 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 colord /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context system_u:system_r:colord_t:s0
Target Context system_u:system_r:unconfined_service_t:s0
Target Objects /proc/<pid>/cgroup [ file ]
Source colord
Source Path /usr/libexec/colord
Port <Unknown>
Host lts1
Source RPM Packages colord-1.2.7-2.el7.x86_64
Target RPM Packages
Policy RPM selinux-policy-3.13.1-60.el7_2.7.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Permissive
Host Name lts1
Platform Linux lts1 3.10.0-327.28.3.el7.x86_64 #1 SMP Thu
Aug 18 19:05:49 UTC 2016 x86_64 x86_64
Alert Count 3
First Seen 2016-09-15 13:55:22 PDT
Last Seen 2016-09-19 07:52:07 PDT
Local ID 434ada73-b86d-4f41-aa11-c57156ca92cd

Raw Audit Messages
type=AVC msg=audit(1474296727.169:3653): avc: denied { getattr } for pid=3188 comm="colord" path="/proc/34315/cgroup" dev="proc" ino=4436946 scontext=system_u:system_r:colord_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=file


type=SYSCALL msg=audit(1474296727.169:3653): arch=x86_64 syscall=fstat success=yes exit=0 a0=e a1=7ffcb6a50180 a2=7ffcb6a50180 a3=0 items=0 ppid=1 pid=3188 auid=4294967295 uid=995 gid=992 euid=995 suid=995 fsuid=995 egid=992 sgid=992 fsgid=992 tty=(none) ses=4294967295 comm=colord exe=/usr/libexec/colord subj=system_u:system_r:colord_t:s0 key=(null)

Hash: colord,colord_t,unconfined_service_t,file,getattr

Post Reply