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><!--
/* 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(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.