August 2016 - selinux - Fedora Mailing-Lists

by Philip Seeley

Hi all, Quick question is: In the targeted policy should init run SystemHigh as it does in the mls policy? The background: We're setting up a targeted system where we confine all users and remove the unconfined policy module, but we also enable polyinstantiation of /tmp and /var/tmp. If we ssh in as a staff_u user phil and elevate to root/sysadm_r then we have a context of: staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 And therefore /var/tmp is: drwxrwxrwt. root root system_u:object_r:tmp_t:s0-s0:c0.c1023 /var/tmp Which is really: drwxrwxrwt. root root system_u:object_r:tmp_t:s0-s0:c0.c1023 /var/tmp-inst/system_u:object_r:tmp_t:s0-s0:c0.c1023_phil The real /var/tmp is: drwxrwxrwt. root root system_u:object_r:tmp_t:s0 /var/tmp Now if we use run_init to update an RPM that contains a post install script, rpm can't create the temporary script file: # run_init bash -c 'rpm -i --force /root/libselinux-2.0.94-7.el6.x86_64.rpm' Authenticating phil. Password: error: error creating temporary file /var/tmp/rpm-tmp.atkHTf: Permission denied error: Couldn't create temporary file for %post (libselinux-2.0.94-7.el6.x86_64): Permission denied Note: you need to use run_init as the rpm might restart a service, e.g. the sssd rpm. We've traced this to the /etc/selinux/targeted/contexts/initrc_context file which contains: system_u:system_r:initrc_t:s0 So we transition to initrc_t and then to rpm_t without any categories, but because the polyinstantiated /var/tmp directory has c0.c1023 we get denied. Normally in targeted init runs unconfined, but we've removed this. type=AVC msg=audit(1467342325.016:716): avc: denied { read } for pid=2779 comm="rpm" name="system_u:object_r:tmp_t:s0-s0:c0.c1023_phil" dev=dm-0 ino=1966082 scontext=system_u:system_r:rpm_t:s0 tcontext=system_u:object_r:tmp_t:s0-s0:c0.c1023 tclass=dir It works if we change initrc_context to: system_u:system_r:initrc_t:s0-s0:c0.c1023 We don't see the issue under mls because the default initrc_context is: system_u:system_r:initrc_t:s0-s15:c0.c1023 We've traces this back through the selinux-policy src RPM and to the upstream refpolicy and see that config/appconfig-mcs/initrc_context is: system_u:system_r:initrc_t:s0 whereas config/appconfig-mls/initrc_context is: system_u:system_r:initrc_t:s0-mls_systemhigh So under mls init's context is SystemHigh, but under mcs/targeted it doesn't have any categories. So the long question is should config/appconfig-mcs/initrc_context really be: system_u:system_r:initrc_t:mcs_systemhigh as it seems odd that the more secure mls policy would run init at SystemHigh but targeted doesn't. Thanks Phil Seeley

4 years, 4 months

3
3
0 / 0

Re: RHEL 7 consoletype_exec interface issue

by Douglas Brown

Hi, In RHEL 7 when using the userdom_unpriv_user_template interface to create a new role, it in turn uses the consoletype_exec interface; but when I attempt to insert a policy compiled with this, it says the type consoletype_exec_t doesn’t exist. N.B. This works on RHEL 6. Thanks, Doug

6 years, 8 months

3
2
0 / 0

Fedora 24 selinux issues

by David Highley

We have been seeing this in dmesg since upgrading our systems to fedora 24. Unable to fix SELinux security context of /run/mdadm/md127.sock: Permission denied If you do a restorecon of course it does not stick across reboots. It also does not show up in an ausearch. The following has just started occurring when we try and run a libvirt VM. Error starting domain: SELinux policy denies access. Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 88, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/asyncjob.py", line 124, in tmpcb callback(*args, **kwargs) File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 83, in newfn ret = fn(self, *args, **kwargs) File "/usr/share/virt-manager/virtManager/domain.py", line 1404, in startup self._backend.create() File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1035, in create if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) libvirtError: SELinux policy denies access. We put the system in Permissive mode and VM will run but no AVC is logged. There are several seboleans that might fix this but we have never needed to use any before.

7 years, 3 months

2
1
0 / 0

RE: selinux Digest, Vol 150, Issue 4

by William Hargrove

unsubscribe -----Original Message----- From: selinux-request(a)lists.fedoraproject.org [mailto:selinux-request@lists.fedoraproject.org] Sent: 15 August 2016 11:38 To: selinux(a)lists.fedoraproject.org Subject: selinux Digest, Vol 150, Issue 4 Send selinux mailing list submissions to selinux(a)lists.fedoraproject.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.fedoraproject.org/admin/lists/selinux@lists.fedoraproject.org or, via email, send a message with subject or body 'help' to selinux-request(a)lists.fedoraproject.org You can reach the person managing the list at selinux-owner(a)lists.fedoraproject.org When replying, please edit your Subject line so it is more specific than "Re: Contents of selinux digest..." Today's Topics: 1. RE: Switching to monolithic policy (Jack_Fewx(a)Dell.com) 2. Fwd: SELinux does not apply file context to unix domain socket (JONIK NSK) 3. Re: xpra printer forwarding currently requires a change to the core policy (Miroslav Grepl) 4. Re: Fwd: SELinux does not apply file context to unix domain socket (Miroslav Grepl) 5. Re: Switching to monolithic policy (Miroslav Grepl) ---------------------------------------------------------------------- Date: Sun, 14 Aug 2016 21:39:37 +0000 From: <Jack_Fewx(a)Dell.com> Subject: RE: Switching to monolithic policy To: <sagivdev(a)gmail.com> Cc: selinux(a)lists.fedoraproject.org Message-ID: <edf4564bb5714547afd7912566e9301e(a)AUSX13MPC104.AMER.DELL.COM> Content-Type: multipart/alternative; boundary="_000_edf4564bb571454 7afd7912566e9301eAUSX13MPC104AMERDELLCOM_" --_000_edf4564bb5714547afd7912566e9301eAUSX13MPC104AMERDELLCOM_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Take a look at how the OE meta-selinux layer handles it. They rewrote the = recipe to build it in 2 stages. Stage one produces the policy modules. Sta= ge two is the compilation of the binary policy (semodule call), utilizing t= he fakeroot/pseudo environment in order to build the monolithic policy. I successfully applied the recipe to the Fedora reference policy with some = modifications. Jack Fewx Platform Software Senior Engineer Dell | Enterprise Product Group -----Original Message----- From: sagivdev(a)gmail.com [mailto:sagivdev@gmail.com] Sent: Sunday, August 14, 2016 7:43 AM To: selinux(a)lists.fedoraproject.org Subject: Re: Switching to monolithic policy Update: In case anyone will stumble upon this error in the future: >From my understanding, the error occurs because monolithic policy in >the op= enembedded environemnt are by default compiled and installed on the host ma= chine (as opposed to modular policies). I have not solved this completly just yet, but I think this is the main iss= ue. I will continue to work on this and also look into the suggestions post= ed by James and Miroslav and post here if i manage to solve the issue. Thanks, Sagiv. -- selinux mailing list selinux(a)lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/selinux@lists.fedoraproject.org --_000_edf4564bb5714547afd7912566e9301eAUSX13MPC104AMERDELLCOM_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> <p class=3D"MsoNormal">Take a look at how the OE meta-selinux layer handles= it.  They rewrote the recipe to build it in 2 stages.  Stage one= produces the policy modules. Stage two is the compilation of the binary po= licy (semodule call), utilizing the fakeroot/pseudo environment in order to build the monolithic policy.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">I successfully applied the recipe to the Fedora refe= rence policy with some modifications.<o:p></o:p></p> <p>Jack Fewx<br> Platform Software Senior Engineer<br> Dell | Enterprise Product Group<br> <br> <br> -----Original Message-----<br> From: sagivdev(a)gmail.com [mailto:sagivdev@gmail.com] <br> Sent: Sunday, August 14, 2016 7:43 AM<br> To: selinux(a)lists.fedoraproject.org<br> Subject: Re: Switching to monolithic policy<br> <br> Update: In case anyone will stumble upon this error in the future:<br> <br> >From my understanding, the error occurs because monolithic policy in >the op= enembedded environemnt are by default compiled and installed on the host ma= chine (as opposed to modular policies).<br> <br> I have not solved this completly just yet, but I think this is the main iss= ue. I will continue to work on this and also look into the suggestions post= ed by James and Miroslav and post here if i manage to solve the issue.<br> <br> Thanks,<br> Sagiv.<br> --<br> selinux mailing list<br> selinux(a)lists.fedoraproject.org<br> https://lists.fedoraproject.org/admin/lists/selinux@lists.fedoraproject.org= <o:p></o:p></p> </div> </body> </html> --_000_edf4564bb5714547afd7912566e9301eAUSX13MPC104AMERDELLCOM_-- ------------------------------ Date: Mon, 15 Aug 2016 14:56:05 +0700 From: JONIK NSK <joniknsk(a)gmail.com> Subject: Fwd: SELinux does not apply file context to unix domain socket To: selinux(a)lists.fedoraproject.org Message-ID: <CAM_56dEPU+hRrhFefLd0Zd=2vc+eut4nmzY4exc0TUYnO7EH7Q(a)mail.gmail.com> Content-Type: multipart/alternative; boundary=047d7bacbfb6a9200b053a17913d --047d7bacbfb6a9200b053a17913d Content-Type: text/plain; charset=UTF-8 Hi! I did some research and have successfully solved topic's problem. First issue is that the path /opt/netbox/netbox/netbox/gunicorn\.sock in file context rule was not an real filesystem path, because the middle netbox component was a symlink to netbox-1.x.x, therefore restorecon did not work. Second issue is that the daemon actually recreates the socket file, and socket inherits its parent dir context (thanks to Philip for this hint), therefore file actually has a usr_t context. Thus, I created a directory /opt/netbox/run for the runtime-environment and set on it the httpd_var_run_t file context: # semanage fcontext -l | grep netbox /opt/netbox/run(/.*)? all files system_u:object_r:httpd_var_run_t:s0 Next, I defined the socket path in my app configuration to this directory: bind = 'unix:/opt/netbox/run/gunicorn.sock' Finally, I restarted app, and the socket is created with the correct context: # ls -lZ /opt/netbox/run/gunicorn.sock srwxrwxrwx. netbox nginx system_u:object_r:httpd_var_run_t:s0 /opt/netbox/run/gunicorn.sock Hope that this will help someone. --047d7bacbfb6a9200b053a17913d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-size:small">Hi!= <br></div><div class=3D"gmail_quote"><div dir=3D"ltr"><div style=3D"font-si= ze:small"><br></div><div><div>I did some research and have successfully sol= ved topic's problem.</div><div><br></div><div><div>First issue is that = the path <font face=3D"monospace, monospace">/opt/netbox/netbox/netbox/<wbr= >gunicorn\.sock</font> in file context rule was not an real filesystem >path= , because the middle <font face=3D"monospace, monospace">netbox</font> comp= onent was a symlink to <font face=3D"monospace, monospace">netbox-1.x.x</fo= nt>, therefore <font face=3D"monospace, monospace">restorecon</font> did nt>no= t work.</div><div><br></div><div>Second issue is that the daemon actually r= ecreates the socket file, and socket inherits its parent dir context (thank= s to Philip for this hint), therefore file actually has a <font face=3D"mon= ospace, monospace">usr_t</font> context.=C2=A0</div></div><div><br></div><d= iv>Thus, I created a directory<font face=3D"monospace, monospace"> iv>/opt/net= box/run</font> for the runtime-environment and set on it the <font face=3D"= monospace, monospace">httpd_var_run_t</font> file context:</div><div><br></= div><div><font face=3D"monospace, monospace"># semanage fcontext -l | div>grep = netbox</font></div><div><font face=3D"monospace, monospace">/opt/netbox/run= (/.*)? =C2=A0 =C2=A0all files =C2=A0 =C2=A0system_u:object_r:httpd_var_<wbr= >run_t:s0</font></div><div><br></div><div>Next, I defined the socket >path i= n my app configuration to this directory:</div><div><br></div><div><font fa= ce=3D"monospace, monospace">bind =3D 'unix:/opt/netbox/run/<wbr>gunicor= n.sock'</font></div><div><br></div><div>Finally, I restarted app, and t= he socket is created with the correct context:</div><div><br></div><div><fo= nt face=3D"monospace, monospace"># ls -lZ /opt/netbox/run/gunicorn.sock</fo= nt></div><div><font face=3D"monospace, monospace">srwxrwxrwx. netbox nt>nginx = system_u:object_r:httpd_var_<wbr>run_t:s0 /opt/netbox/run/gunicorn.sock</fo= nt></div><div><br></div><div>Hope that this will help nt>someone.</div></div><= /div></div></div> --047d7bacbfb6a9200b053a17913d-- ------------------------------ Date: Mon, 15 Aug 2016 11:42:05 +0200 From: Miroslav Grepl <mgrepl(a)redhat.com> Subject: Re: xpra printer forwarding currently requires a change to the core policy To: Antoine Martin <antoine(a)nagafix.co.uk>, selinux(a)lists.fedoraproject.org Message-ID: <d018fc8b-fc19-0128-d7a2-14c932f2cadf(a)redhat.com> Content-Type: text/plain; charset=utf-8 On 08/12/2016 02:27 PM, Antoine Martin wrote: >>>> We could try to label xpra by a label to get it running in a >>>> different CUPS domain. >>>> > (snip) >>> >>> So maybe do something similar to cups_pdf_exec_t for xpraforwarder, >>> with the extra privileges needed for accessing the socket? >> >> Yes, I was looking for the backend. Could you try to label the >> backend by cups_pdf_exec_t to see how it works? > That didn't work, but this does: > chcon -t cups_pdf_exec_t /usr/lib/cups/backend/xpraforwarder > And then load this module on top: > > module xpraforwarder 1.0; > require { > type user_tmp_t; > type cups_pdf_t; > type unconfined_t; > class unix_dgram_socket create; > class unix_dgram_socket connect; > class sock_file write; > class unix_stream_socket connectto; > } > allow cups_pdf_t self:unix_dgram_socket { create connect }; allow > cups_pdf_t user_tmp_t:sock_file write; allow cups_pdf_t > unconfined_t:unix_stream_socket connectto; > > Full details here: > http://xpra.org/trac/ticket/815#comment:7 > > I then tried to extract the bits from the cups / cups_pdf policy to > try to come with something more self-contained for xpra and although I > did come up with something that works OK and does not depend on > cups_pdf_t, the resulting policy is a lot bigger than I would like (but it works!): > http://xpra.org/trac/changeset/13317 > > Any feedback would be most appreciated, I'm sure there are glaring > mistakes in there. > I often find myself wondering how I can reduce those long winded > statements to more helpful macros - that is, without spending hours > figuring it all out. How can I get it done more efficiently? You can use "policy_module(cups_xpra, 1.0)" which means you generate module policy using reference policy and you don't need to require all these classes with permissions. Together that look for *.if to avoid the "require" section if possible. So for example ---- policy_module(cups_xpra, 1.0) type cups_xpra_t; type cups_xpra_exec_t; cups_backend(cups_xpra_t, cups_xpra_exec_t) # # interfaces are placed in /usr/share/selinux/devel/ # unconfined_stream_connect(cups_xpra_t) --- and # make -f /usr/share/selinux/devel/Makefile cups_xpra.pp # semodule -i cups_xpra.pp Also https://github.com/TresysTechnology/refpolicy/wiki could be helpful. > > Thanks > Antoine > > >> >> Thank you. >> >>> >>> Thanks >>> Antoine >>> -- >>> selinux mailing list >>> selinux(a)lists.fedoraproject.org >>> https://lists.fedoraproject.org/admin/lists/selinux@lists.fedoraproj >>> ect.org >>> >> >> > -- > selinux mailing list > selinux(a)lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/selinux@lists.fedoraprojec > t.org > -- Miroslav Grepl Senior Software Engineer, SELinux Solutions Red Hat, Inc. ------------------------------ Date: Mon, 15 Aug 2016 11:48:10 +0200 From: Miroslav Grepl <mgrepl(a)redhat.com> Subject: Re: Fwd: SELinux does not apply file context to unix domain socket To: selinux(a)lists.fedoraproject.org Message-ID: <3fd2a071-bb1e-438c-ff68-9b04c5c65fd2(a)redhat.com> Content-Type: text/plain; charset=utf-8 On 08/15/2016 09:56 AM, JONIK NSK wrote: > Hi! > > I did some research and have successfully solved topic's problem. > > First issue is that the path /opt/netbox/netbox/netbox/gunicorn\.sock > in file context rule was not an real filesystem path, because the > middle netbox component was a symlink to netbox-1.x.x, therefore > restorecon did not work. > > Second issue is that the daemon actually recreates the socket file, > and socket inherits its parent dir context (thanks to Philip for this > hint), therefore file actually has a usr_t context. > > Thus, I created a directory/opt/netbox/run for the runtime-environment > and set on it the httpd_var_run_t file context: > > # semanage fcontext -l | grep netbox > /opt/netbox/run(/.*)? all files system_u:object_r:httpd_var_run_t:s0 > > Next, I defined the socket path in my app configuration to this directory: > > bind = 'unix:/opt/netbox/run/gunicorn.sock' > > Finally, I restarted app, and the socket is created with the correct > context: > > # ls -lZ /opt/netbox/run/gunicorn.sock srwxrwxrwx. netbox nginx > system_u:object_r:httpd_var_run_t:s0 > /opt/netbox/run/gunicorn.sock > > Hope that this will help someone. Yeap, that's a nice solution. What is your directory structure under /opt/netbox/run? There is a chance to define a file context equivalence using semanage-fcontext. So for example # semanage fcontext -a -e / /opt/netbox # restorecon -R -v /opt/netbox > > > -- > selinux mailing list > selinux(a)lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/selinux@lists.fedoraprojec > t.org > -- Miroslav Grepl Senior Software Engineer, SELinux Solutions Red Hat, Inc. ------------------------------ Date: Mon, 15 Aug 2016 12:38:00 +0200 From: Miroslav Grepl <mgrepl(a)redhat.com> Subject: Re: Switching to monolithic policy To: selinux(a)lists.fedoraproject.org Message-ID: <0af430b9-abb3-c60d-20f2-2e8d44b595b9(a)redhat.com> Content-Type: text/plain; charset=utf-8 On 08/14/2016 02:43 PM, sagivdev(a)gmail.com wrote: > Update: In case anyone will stumble upon this error in the future: > > From my understanding, the error occurs because monolithic policy in the openembedded environemnt are by default compiled and installed on the host machine (as opposed to modular policies). > > I have not solved this completly just yet, but I think this is the main issue. I will continue to work on this and also look into the suggestions posted by James and Miroslav and post here if i manage to solve the issue. > Maybe you could also try to ask on refpolicy(a)oss.tresys.com. > Thanks, > Sagiv. > -- > selinux mailing list > selinux(a)lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/selinux@lists.fedoraprojec > t.org > -- Miroslav Grepl Senior Software Engineer, SELinux Solutions Red Hat, Inc. ------------------------------ Subject: Digest Footer -- selinux mailing list selinux(a)lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/selinux@lists.fedoraproject.org ------------------------------ End of selinux Digest, Vol 150, Issue 4 *************************************** The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44(020 7896 0011) and then delete the email and any copies of it. Opinions, conclusion (etc) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG is a trading name of IG Markets Limited (a company registered in England and Wales, company number 04008957) and IG Index Limited (a company registered in England and Wales, company number 01190902). Registered address at Cannon Bridge House, 25 Dowgate Hill, London EC4R 2YA. Both IG Markets Limited (register number 195355) and IG Index Limited (register number 114059) are authorised and regulated by the Financial Conduct Authority.

7 years, 3 months

1
0
0 / 0

Switching to monolithic policy

by sagivdev＠gmail.com

Hello all, I am new to SELinux. my goal is to implement a custom, small policy on an embedded device. Currently, i have a working modified (narrowed down) policy based on the targeted refpolicy. I use a custom openembedded environment. My thought was that since I aim to use the policy on an embedded device (so no changes should be made to the policy at all), using a monolithic policy will save space and I could also give up on the managing tools, reducing more space. I am having trouble switching to monolithic policy. I wanted to made sure that the errors was not resulting from my specific rules, so i reverted for now to the regular targeted refpolicy that arrives with the openembedded SELinux meta. This is the resulting error: | Creating targeted policy.conf | Compiling targeted policy.29 | policy/modules/roles/sysadm.te:78:ERROR 'duplicate role transition for (sysadm_r,abrt_initrc_exec_t,process)' at token ';' on line 2454354: | #line 78 | role_transition sysadm_r abrt_initrc_exec_t system_r; | checkpolicy: error(s) encountered while parsing configuration | /lte/sagivde/local_views/sagivde_selinux_policy_1/vobs/le920/apps_proc/oe-core/build/tmp-glibc/sysroots/x86_64-linux/usr/bin/checkpolicy: loading policy configuration from policy.conf | make: *** [policy.29] Error 1 If I comment out the above rule a different error occurs, and this happens for again for the next error and so on.. my questions are: 1. Is moving to monolithic policy really a good choice in my case? (reduce memory consumption and disk space) 2. If so - how can i solve the above error? Thanks, Sagiv.

7 years, 3 months

4
5
1 / 0

Fwd: SELinux does not apply file context to unix domain socket

by JONIK NSK

Hi! I did some research and have successfully solved topic's problem. First issue is that the path /opt/netbox/netbox/netbox/gunicorn\.sock in file context rule was not an real filesystem path, because the middle netbox component was a symlink to netbox-1.x.x, therefore restorecon did not work. Second issue is that the daemon actually recreates the socket file, and socket inherits its parent dir context (thanks to Philip for this hint), therefore file actually has a usr_t context. Thus, I created a directory /opt/netbox/run for the runtime-environment and set on it the httpd_var_run_t file context: # semanage fcontext -l | grep netbox /opt/netbox/run(/.*)? all files system_u:object_r:httpd_var_run_t:s0 Next, I defined the socket path in my app configuration to this directory: bind = 'unix:/opt/netbox/run/gunicorn.sock' Finally, I restarted app, and the socket is created with the correct context: # ls -lZ /opt/netbox/run/gunicorn.sock srwxrwxrwx. netbox nginx system_u:object_r:httpd_var_run_t:s0 /opt/netbox/run/gunicorn.sock Hope that this will help someone.

7 years, 3 months

2
1
0 / 0

xpra printer forwarding currently requires a change to the core policy

by Antoine Martin

xpra printer forwarding works by adding a PDF or PS virtual printer via a cups backend. This cups backend then connects to the local xpra server via a unix domain socket and the server then forwards the PDF or PS file to the xpra client for printing. The problem is connecting to the xpra server socket, which is currently forbidden by the core policy. Here's what we have to add to make it work at the moment with the server socket in "~/.xpra/": userdom_manage_user_home_content_files(cupsd_t) userdom_manage_user_home_content_symlinks(cupsd_t) userdom_manage_user_home_content_pipes(cupsd_t) userdom_manage_user_home_content_sockets(cupsd_t) Alternatively, if that helps, we can also place the server socket in /run/user/$UID/xpra, but then we still get: type=AVC msg=audit(1470902846.451:911): avc: denied { write } for pid=9644 comm="xpra" name="desktop-100" dev="tmpfs" ino=74293 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=sock_file permissive=1 type=AVC msg=audit(1470902846.451:912): avc: denied { connectto } for pid=9644 comm="xpra" path="/run/user/1000/xpra/desktop-100" scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket permissive=1 What is the preferred way forward to allow users to have both selinux in enforcing mode and printing to work with xpra by default?

7 years, 3 months

3
6
0 / 0

SELinux does not apply file context to unix domain socket

by JONIK NSK

Hello, I'm trying to configure and run Django application behind Nginx reverse-proxy. My system is latest CentOS 7.2, SELinux is in Enforcing mode, selinux-policy-targeted-3.13.1-60.el7_2.7.noarch. From audit.log messages I see, that SELinux prevent Nginx daemon access to socket file: type=AVC msg=audit(1470659579.411:2693): avc: denied { write } for pid=34378 comm="nginx" name="gunicorn.sock" dev="dm-1" ino=921257 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=sock_file type=SYSCALL msg=audit(1470659579.411:2693): arch=c000003e syscall=42 success=no exit=-13 a0=e a1=2513ce8 a2=6e a3=7ffd54ae92f0 items=0 ppid=34376 pid=34378 auid=4294967295 uid=992 gid=989 euid=992 suid=992 fsuid=992 egid=989 sgid=989 fsgid=989 tty=(none) ses=4294967295 comm="nginx" exe="/usr/sbin/nginx" subj=system_u:system_r:httpd_t:s0 key=(null) type=AVC msg=audit(1470659579.597:2694): avc: denied { write } for pid=34378 comm="nginx" name="gunicorn.sock" dev="dm-1" ino=921257 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=sock_file Socket file is owned by Gunicorn user and has context usr_t, inherited from /opt/.* rule: srwxrwxrwx. netbox nginx system_u:object_r:usr_t:s0 /opt/netbox/netbox/netbox/gunicorn.sock From output of # sesearch -A -s httpd_t | grep sock_file I found rule that allows nginx (httpd_t) access to sock_file with httpd_var_run_t context: allow httpd_t httpd_var_run_t : sock_file { ioctl read write create getattr setattr lock append unlink link rename open } ; Next, I add that file context for my socket file location with s-filetype: # semanage fcontext -a -f s -t httpd_var_run_t '/opt/netbox/netbox/netbox/gunicorn\.sock' Removing and recreating socket file did not solve my problem - file still has a context usr_t :( Gunicorn started by systemd and has context system_u:system_r:unconfined_service_t:s0 Furthermore, restorecon -v /opt/netbox/netbox/netbox/gunicorn.sock does not effect to applying httpd_var_run_t context to existing file! I'm confused - I make something wrong or there is a bug in SELinux labeling? Thanks for replies!

7 years, 4 months

3
2
1 / 0

RE: --EXTERNAL--Welcome to the "selinux" mailing list

by Parker, Michael D.

What are you all doing/have done to boot strap your knowledge about SELinux? ***** ***** ***** Michael D. Parker General Atomics - EMS Michael.d.parker(a)ga.com<mailto:Michael.d.parker@ga.com> <<<<< NOTE: Remember to include my middle initial >>>>> +1 858 964 6675 / Office 86-1319 16969 Mesamint Street / San Diego / CA / 92127 ************************************************************************ CONFIDENTIALITY NOTICE: This communication is intended to be confidential to the person(s) to whom it is addressed. If you are not the intended recipient or the agent of the intended recipient or if you are unable to deliver this communication to the intended recipient, you must not read, use or disseminate this information. If you have received this communication in error,please advise the sender immediately by telephone and delete this messageand any attachments without retaining a copy. *************************************************************************

7 years, 4 months

6
6
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux August 2016