Hi!=3D

I did some research and have s= uccessfully sol=3D ved topic's problem.

Fir= st issue is that =3D the path /opt/netb= ox/netbox/netbox/gunicorn\.sock in file context rule was not an real filesystem >path=3D , because the middle netbox comp= =3D onent was a symlink to netbox-1.x.x= , therefore restorecon did nt>no=3D t work.

Second issue is that the daemon actually r= =3D ecreates the socket file, and socket inherits its parent dir context (tha= nk=3D s to Philip for this hint), therefore file actually has a usr_t context.=3DC2=3DA0

Thus, I created a directory iv>/opt/net=3D box/run for the runtime-environment and set on it the httpd_var_run_t file context:

# semanage fcontext -l | div>grep =3D netbox

/opt/netbox/run= =3D (/.*)? =3DC2=3DA0 =3DC2=3DA0all files =3DC2=3DA0 =3DC2=3DA0system_u:objec= t_r:httpd_var_run_t:s0

Next, I defined the socket >path i=3D n my app configuration to this directory:

bind =3D3D 'unix:/opt/netbox/run/g= unicor=3D n.sock'

Finally, I restarted app, and t= =3D he socket is created with the correct context:

<= fo=3D nt face=3D3D"monospace, monospace"># ls -lZ /opt/netbox/run/gunicorn.sock

srwxrwxrwx. netbox nt>nginx =3D system_u:object_r:httpd_var_run_t:s0 /opt/netbox/run/gunicorn.sock

Hope that this will help nt>someone.

<=3D /div>

--047d7bacbfb6a9200b053a17913d-- ------------------------------ Date: Mon, 15 Aug 2016 11:42:05 +0200 From: Miroslav Grepl Subject: Re: xpra printer forwarding currently requires a change to the core policy To: Antoine Martin , selinux(a)lists.fedoraproject.org Message-ID: Content-Type: text/plain; charset=3Dutf-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 n= eed to require all these classes with permissions. Together that look for *.i= f 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_x= pra.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(a)lists.fedoraproj >>> ect.org >>> >> >> > -- > selinux mailing list > selinux(a)lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/selinux(a)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 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=3Dutf-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 =3D '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/net= box/run? There is a chance to define a file context equivalence using semanage-fcontex= t. 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(a)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 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=3Dutf-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 op= enembedded environemnt are by default compiled and installed on the host mach= ine (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 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(a)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(a)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 int= ended recipient, please do not read, copy, use or disclose to others this mes= sage or any attachment. Please also notify the sender by replying to this ema= il or by telephone (+44(020 7896 0011) and then delete the email and any copi= es of it. Opinions, conclusion (etc) that do not relate to the official busin= ess 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 a= nd 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 (reg= ister number 195355) and IG Index Limited (register number 114059) are author= ised and regulated by the Financial Conduct Authority. --===============7549174160132440872==--