unsubscribe -----Original Message----- From: selinux-request@xxxxxxxxxxxxxxxxxxxxxxx [mailto:selinux-request@xxxxxxxxxxxxxxxxxxxxxxx] Sent: 15 August 2016 11:38 To: selinux@xxxxxxxxxxxxxxxxxxxxxxx Subject: selinux Digest, Vol 150, Issue 4 Send selinux mailing list submissions to selinux@xxxxxxxxxxxxxxxxxxxxxxx To subscribe or unsubscribe via the World Wide Web, visit https://lists.fedoraproject.org/admin/lists/selinux@xxxxxxxxxxxxxxxxxxxxxxx or, via email, send a message with subject or body 'help' to selinux-request@xxxxxxxxxxxxxxxxxxxxxxx You can reach the person managing the list at selinux-owner@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxx) 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@xxxxxxxx> Subject: RE: Switching to monolithic policy To: <sagivdev@xxxxxxxxx> Cc: selinux@xxxxxxxxxxxxxxxxxxxxxxx Message-ID: <edf4564bb5714547afd7912566e9301e@xxxxxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx [mailto:sagivdev@xxxxxxxxx] Sent: Sunday, August 14, 2016 7:43 AM To: selinux@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/selinux@xxxxxxxxxxxxxxxxxxxxxxx --_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><!-- /* Font Definitions */ @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:"\@SimSun"; panose-1:2 1 6 0 3 1 1 1 1 1;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri",sans-serif;} a:link, span.MsoHyperlink {mso-style-priority:99; color:#0563C1; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:#954F72; text-decoration:underline;} p {mso-style-priority:99; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:12.0pt; font-family:"Times New Roman",serif;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri",sans-serif; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt; font-family:"Calibri",sans-serif;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </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@xxxxxxxxx [mailto:sagivdev@xxxxxxxxx] <br> Sent: Sunday, August 14, 2016 7:43 AM<br> To: selinux@xxxxxxxxxxxxxxxxxxxxxxx<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@xxxxxxxxxxxxxxxxxxxxxxx<br> https://lists.fedoraproject.org/admin/lists/selinux@xxxxxxxxxxxxxxxxxxxxxxx= <o:p></o:p></p> </div> </body> </html> --_000_edf4564bb5714547afd7912566e9301eAUSX13MPC104AMERDELLCOM_-- ------------------------------ Date: Mon, 15 Aug 2016 14:56:05 +0700 From: JONIK NSK <joniknsk@xxxxxxxxx> Subject: Fwd: SELinux does not apply file context to unix domain socket To: selinux@xxxxxxxxxxxxxxxxxxxxxxx Message-ID: <CAM_56dEPU+hRrhFefLd0Zd=2vc+eut4nmzY4exc0TUYnO7EH7Q@xxxxxxxxxxxxxx> 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@xxxxxxxxxx> Subject: Re: xpra printer forwarding currently requires a change to the core policy To: Antoine Martin <antoine@xxxxxxxxxxxxx>, selinux@xxxxxxxxxxxxxxxxxxxxxxx Message-ID: <d018fc8b-fc19-0128-d7a2-14c932f2cadf@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx >>> https://lists.fedoraproject.org/admin/lists/selinux@lists.fedoraproj >>> ect.org >>> >> >> > -- > selinux mailing list > selinux@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxx> Subject: Re: Fwd: SELinux does not apply file context to unix domain socket To: selinux@xxxxxxxxxxxxxxxxxxxxxxx Message-ID: <3fd2a071-bb1e-438c-ff68-9b04c5c65fd2@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxx> Subject: Re: Switching to monolithic policy To: selinux@xxxxxxxxxxxxxxxxxxxxxxx Message-ID: <0af430b9-abb3-c60d-20f2-2e8d44b595b9@xxxxxxxxxx> Content-Type: text/plain; charset=utf-8 On 08/14/2016 02:43 PM, sagivdev@xxxxxxxxx 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@xxxxxxxxxxxxxx. > Thanks, > Sagiv. > -- > selinux mailing list > selinux@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/selinux@xxxxxxxxxxxxxxxxxxxxxxx ------------------------------ 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. -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/selinux@xxxxxxxxxxxxxxxxxxxxxxx
