Initial context for init
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, 10 months
Is this an error that should be BZ'd?
by Ed Greshko
I was having some problems with getting a setting to stick under network
manager. I wanted to eliminate a silent selinux AVC. So I issued a
semodule -DB. This is on F25, BTW.
But now I'm continuously getting the following....
SELinux is preventing systemd from 'read, write' accesses on the
unix_stream_socket unix_stream_socket.
***** Plugin catchall (100. confidence) suggests
**************************
If you believe that systemd should be allowed read write access on the
unix_stream_socket unix_stream_socket 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:
# ausearch -c 'systemd' --raw | audit2allow -M my-systemd
# semodule -X 300 -i my-systemd.pp
Additional Information:
Source Context system_u:system_r:init_t:s0
Target Context system_u:system_r:kernel_t:s0-s0:c0.c1023
Target Objects unix_stream_socket [ unix_stream_socket ]
Source systemd
Source Path systemd
Port <Unknown>
Host meimei.greshko.com
Source RPM Packages
Target RPM Packages
Policy RPM <Unknown>
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name meimei.greshko.com
Platform Linux meimei.greshko.com
4.10.8-200.fc25.x86_64 #1
SMP Fri Mar 31 13:20:22 UTC 2017 x86_64 x86_64
Alert Count 2
First Seen 2017-04-11 13:59:41 CST
Last Seen 2017-04-11 13:59:41 CST
Local ID a9f3060f-290b-4777-bf8f-28d0313ca9f1
Raw Audit Messages
type=AVC msg=audit(1491890381.516:407): avc: denied { read write }
for pid=1 comm="systemd" path="socket:[65875]" dev="sockfs" ino=65875
scontext=system_u:system_r:init_t:s0
tcontext=system_u:system_r:kernel_t:s0-s0:c0.c1023
tclass=unix_stream_socket permissive=0
Hash: systemd,init_t,kernel_t,unix_stream_socket,read,write
Should I follow the recommendation of generating a local policy? Should
this be BZ'd?
--
Fedora Users List - The place to go to get others to do the work for you
7 years, 1 month
Is it possible speed-up useradd -Z option?
by Lakshmipathi.G
It takes 10 seconds to create user account,where as without -Z option
it takes less a second. I tried changing SELinux to Permissive mode or
try to use tmpfs for /etc/selinux mountpoint , both didn't help.The
problem is I'm re-creating 50000+ user accounts in a new server. Looks
for options to speed-up this process. thanks for
any pointers/help.
# time useradd --uid=20005 -Z guest_u u20005
real 0m10.194s
user 0m8.866s
sys 0m1.273s
# time useradd --uid=20006 u20006
real 0m0.050s
user 0m0.018s
sys 0m0.021s
----
Cheers,
Lakshmipathi.G
http://www.giis.co.in http://www.webminal.org
7 years, 2 months
Re: ipsec module and Libreswan on CentOS 7 denied
by Grzegorz Kuczyński
Hello again :)
This time it work, and this is what I does:
Add to ipsec.conf this options:
secctx-attr-type=32001
This is my config:
[root@CnetOS7 netserver]# cat /etc/ipsec.conf
version 2
config setup
protostack=netkey
secctx-attr-type=32001
conn ipsec_selinux_tunnel
leftid=@west
left=10.5.5.18
leftrsasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...] W2n417C/4urYHQkCvuIQ==
rightid=@east
right=10.5.5.10
rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ==
authby=rsasig
auto=start
labeled_ipsec=yes
policy_label=system_u:object_r:ipsec_spd_t:s0
In my own domain I coment unlabeled_t allow:
netserver.te:
...
allow netserver_t ipsec_t:association { polmatch };
allow ipsec_t netserver_t:association { setcontext };
allow ipsec_t ipsec_spd_t:association { setcontext };
#allow unlabeled_t ipsec_spd_t:association { polmatch };
I start my server and client and I have some denied, so I add to my server
domain:
allow netserver_t netif_t:netif { ingress egress }
allow netserver_t node_t:node { sendto recvfrom }
and client domain:
allow netclient_t netif_t:netif { ingress egress }
allow netclient_t node_t:node { sendto recvfrom }
allow netclient_t netserver_t:peer { recv }
allow netserver_t netclient_t:peer { recv }
Now work properly:
[root@CnetOS7 netserver]# netserver -Z
Listening...
Connected with 10.5.5.10:44998
Client SELinux conntext:
unconfined_u:unconfined_r:netclient_t:s0-s0:c0.c1023
Retrive: quit
[root@CnetOS7 netserver]# ip xfrm state
src 10.5.5.10 dst 10.5.5.18
proto esp spi 0x436be694 reqid 16389 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha1) 0x4c7d6ff6a191951fc69d9c3def070db3e0d59ae5 96
enc cbc(aes) 0x3c624b14b79e6f2dd632d26d36d90ff7
security context unconfined_u:unconfined_r:netserver_t:s0-s0:c0.c1023
src 10.5.5.18 dst 10.5.5.10
proto esp spi 0x3ad8e7fa reqid 16389 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha1) 0x91a06a54d2fd1899229129489bd1d766b8f00990 96
enc cbc(aes) 0x77a17777f44378970ffa25cdd2a8bd34
security context unconfined_u:unconfined_r:netserver_t:s0-s0:c0.c1023
src 10.5.5.18 dst 10.5.5.10
proto esp spi 0x814b2bb1 reqid 16389 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha1) 0x6b72091e994d5790690f8169889e2188b2cbc933 96
enc cbc(aes) 0x5e9d4f9128c995edbf7e46aca6f92950
security context unconfined_u:unconfined_r:netclient_t:s0-s0:c0.c1023
src 10.5.5.10 dst 10.5.5.18
proto esp spi 0xfde27f2f reqid 16389 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha1) 0xdfa421e570976742d24028a00f391857beac5683 96
enc cbc(aes) 0x9c72f2a72726154130f1c8922e0b173e
security context unconfined_u:unconfined_r:netclient_t:s0-s0:c0.c1023
src 10.5.5.10 dst 10.5.5.18
proto esp spi 0x9b25639b reqid 16389 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha1) 0x6adc49b7978217d1a5656b3462f916ef051e43b6 96
enc cbc(aes) 0x4c248f4bc47199b3637b32226d9e7377
src 10.5.5.18 dst 10.5.5.10
proto esp spi 0xc17086fa reqid 16389 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha1) 0x726602fb3a003b0296bd3c59d0c0631ae8b69619 96
enc cbc(aes) 0x167ce87116d07c4d3436c1631fb6efa4
src 10.5.5.10 dst 10.5.5.18
proto esp spi 0xc7ceed20 reqid 16389 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha1) 0x5debc146502f9d8322f79130a695a863a5191edd 96
enc cbc(aes) 0xc66cf0910346412f78aaab9770c98a7d
src 10.5.5.18 dst 10.5.5.10
proto esp spi 0x6b36950c reqid 16389 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha1) 0xe138e77d26e05ffdbfdad7241f505645917a8574 96
enc cbc(aes) 0x874ed487c96261c692672d48e02129f3
So the reason why this not work early is missing option in ipsec.conf?
Or it is still bug?
Thanks to help
2017-04-06 17:53 GMT+02:00 Richard Haines <richard_c_haines(a)btinternet.com>:
> On Tue, 2017-04-04 at 18:43 -0400, Paul Wouters wrote:
> > On 04/04/2017 05:14 PM, Paul Moore wrote:
> > > On Tue, Apr 4, 2017 at 1:43 PM, Stephen Smalley <sds(a)tycho.nsa.gov>
> > > wrote:
> > > > On Tue, 2017-04-04 at 17:09 +0000, Grzegorz Kuczyński wrote:
> > > > > [root@CnetOS7 ~]# ip xfrm state
> > > > > src 10.5.5.18 dst 10.5.5.10
> > > > > proto esp spi 0xedbce21c reqid 16389 mode tunnel
> > > > > replay-window 32 flag af-unspec
> > > > > auth-trunc hmac(sha1)
> > > > > 0x4f8cdee1b453dacf606fcf630d9c5b328b952404 96
> > > > > enc cbc(aes) 0x442da48e8178c4971275b9d889747536
> > > > > src 10.5.5.10 dst 10.5.5.18
> > > > > proto esp spi 0x921bce56 reqid 16389 mode tunnel
> > > > > replay-window 32 flag af-unspec
> > > > > auth-trunc hmac(sha1)
> > > > > 0x7050af8d2c7c151db1ded71d5a4468eaafdc8a29 96
> > > > > enc cbc(aes) 0x8686ccf1127bb881fa382fe17f790d69
> > > > > src 10.5.5.10 dst 10.5.5.18
> > > > > proto esp spi 0xe6ca8cc5 reqid 16389 mode tunnel
> > > > > replay-window 32 flag af-unspec
> > > > > auth-trunc hmac(sha1)
> > > > > 0x3aef0708d244ede7793e328b1937d0b70d425fb7 96
> > > > > enc cbc(aes) 0xa4cc55f6a88307b8f354fc3e8d576276
> > > > > src 10.5.5.18 dst 10.5.5.10
> > > > > proto esp spi 0x5acea75b reqid 16389 mode tunnel
> > > > > replay-window 32 flag af-unspec
> > > > > auth-trunc hmac(sha1)
> > > > > 0x731268575b53cfbd9cac20e988cfc5557d381036 96
> > > > > enc cbc(aes) 0x1defeab6aa6ac729f3082f6b70053918
> > > >
> > > > Hmm...no security contexts? That would explain why you are
> > > > getting
> > > > unlabeled_t. But I guess the question is why is pluto creating
> > > > SAs
> > > > without any security contexts. Seems like a bug there, but I am
> > > > not
> > > > sure.
> >
> > What is the configuration? Was labeled-ipsec=yes and policy-label=
> > set?
> > If dealing with RHEL6 or older, it also needs to have secctx-attr-
> > type=10
> > If not, no security context is set.
> >
> > > https://lists.fedoraproject.org/archives/list/selinux@lists.fedorap
> > > roject.org/thread/AXJWXBVF4ZCSPKQ42MWX5LRTD5PGRS7O
> >
> > Note the references in the documentation to loopback should be
> > removed. It was broken
> > and removed.
> >
> > Was IKEv1 used? IKEv2 does not support security labels so set
> > ikev2=never
> >
> > Log files should indicate if any security label was negotiated.
> >
> > Is this system using MLS?
> >
> > Paul
>
>
> Out of idle curiosity I thought I would test this.
> I set up two machines and finally got this to work. I did have the same
> problem as yourself:
> allow unlabeled_t ipsec_spd_t:association polmatch;
>
> However I did the following to fix this (on both machines running
> Fedora 25 targeted policy):
>
> 1) iptables -I INPUT 1 -p esp -j ACCEPT
>
> 2) Added the following module:
>
> module local 1.0;
>
> require {
> type unconfined_t;
> type ipsec_spd_t;
> type ipsec_t;
> class association setcontext;
> }
>
> #============= ipsec_t ==============
> allow ipsec_t ipsec_spd_t:association setcontext;
>
> # Required because I just run as a basic user. Not sure what you need
> allow ipsec_t unconfined_t:association setcontext;
>
>
>
> One side ipsec.conf file contents:
>
> version 2.0
>
> config setup
> plutorestartoncrash=false
> protostack=netkey
> plutodebug="all"
> # Note: works with either 10 or 32001, however must
> # be same on both machines.
> secctx-attr-type=32001
>
> conn labeled_test
> auto=start
> rekey=no
> authby=secret
> type=transport
> left=192.168.1.77
> right=192.168.1.64
> ike=3des-sha1
> phase2=esp
> phase2alg=aes-sha1
> labeled-ipsec=yes
> policy-label=system_u:object_r:ipsec_spd_t:s0
> leftprotoport=tcp
> rightprotoport=tcp
>
> I could see the correct peer context using getpeercon(3) on my test
> client/server:
> Server Peer Context: unconfined_u:unconfined_r:unconfined_t:s0-
> s0:c0.c1023
> Client Peer Context: unconfined_u:unconfined_r:unconfined_t:s0-
> s0:c0.c1023
>
> Hope you get yours to work now (or you may have it working already ??)
>
> Richard
>
7 years, 2 months
Re: ipsec module and Libreswan on CentOS 7 denied
by Stephen Smalley
On Thu, 2017-04-06 at 16:53 +0100, Richard Haines wrote:
> On Tue, 2017-04-04 at 18:43 -0400, Paul Wouters wrote:
> > On 04/04/2017 05:14 PM, Paul Moore wrote:
> > > On Tue, Apr 4, 2017 at 1:43 PM, Stephen Smalley <sds(a)tycho.nsa.go
> > > v>
> > > wrote:
> > > > On Tue, 2017-04-04 at 17:09 +0000, Grzegorz Kuczyński wrote:
> > > > > [root@CnetOS7 ~]# ip xfrm state
> > > > > src 10.5.5.18 dst 10.5.5.10
> > > > > proto esp spi 0xedbce21c reqid 16389 mode tunnel
> > > > > replay-window 32 flag af-unspec
> > > > > auth-trunc hmac(sha1)
> > > > > 0x4f8cdee1b453dacf606fcf630d9c5b328b952404 96
> > > > > enc cbc(aes) 0x442da48e8178c4971275b9d889747536
> > > > > src 10.5.5.10 dst 10.5.5.18
> > > > > proto esp spi 0x921bce56 reqid 16389 mode tunnel
> > > > > replay-window 32 flag af-unspec
> > > > > auth-trunc hmac(sha1)
> > > > > 0x7050af8d2c7c151db1ded71d5a4468eaafdc8a29 96
> > > > > enc cbc(aes) 0x8686ccf1127bb881fa382fe17f790d69
> > > > > src 10.5.5.10 dst 10.5.5.18
> > > > > proto esp spi 0xe6ca8cc5 reqid 16389 mode tunnel
> > > > > replay-window 32 flag af-unspec
> > > > > auth-trunc hmac(sha1)
> > > > > 0x3aef0708d244ede7793e328b1937d0b70d425fb7 96
> > > > > enc cbc(aes) 0xa4cc55f6a88307b8f354fc3e8d576276
> > > > > src 10.5.5.18 dst 10.5.5.10
> > > > > proto esp spi 0x5acea75b reqid 16389 mode tunnel
> > > > > replay-window 32 flag af-unspec
> > > > > auth-trunc hmac(sha1)
> > > > > 0x731268575b53cfbd9cac20e988cfc5557d381036 96
> > > > > enc cbc(aes) 0x1defeab6aa6ac729f3082f6b70053918
> > > >
> > > > Hmm...no security contexts? That would explain why you are
> > > > getting
> > > > unlabeled_t. But I guess the question is why is pluto creating
> > > > SAs
> > > > without any security contexts. Seems like a bug there, but I
> > > > am
> > > > not
> > > > sure.
> >
> > What is the configuration? Was labeled-ipsec=yes and policy-label=
> > set?
> > If dealing with RHEL6 or older, it also needs to have secctx-attr-
> > type=10
> > If not, no security context is set.
> >
> > > https://lists.fedoraproject.org/archives/list/selinux@lists.fedor
> > > ap
> > > roject.org/thread/AXJWXBVF4ZCSPKQ42MWX5LRTD5PGRS7O
> >
> > Note the references in the documentation to loopback should be
> > removed. It was broken
> > and removed.
> >
> > Was IKEv1 used? IKEv2 does not support security labels so set
> > ikev2=never
> >
> > Log files should indicate if any security label was negotiated.
> >
> > Is this system using MLS?
> >
> > Paul
>
>
> Out of idle curiosity I thought I would test this.
> I set up two machines and finally got this to work. I did have the
> same
> problem as yourself:
> allow unlabeled_t ipsec_spd_t:association polmatch;
>
> However I did the following to fix this (on both machines running
> Fedora 25 targeted policy):
>
> 1) iptables -I INPUT 1 -p esp -j ACCEPT
>
> 2) Added the following module:
>
> module local 1.0;
>
> require {
> type unconfined_t;
> type ipsec_spd_t;
> type ipsec_t;
> class association setcontext;
> }
>
> #============= ipsec_t ==============
> allow ipsec_t ipsec_spd_t:association setcontext;
>
> # Required because I just run as a basic user. Not sure what you need
> allow ipsec_t unconfined_t:association setcontext;
Hmm...that's a policy bug then. pluto and racoon should be allowed
setcontext.
>
>
>
> One side ipsec.conf file contents:
>
> version 2.0
>
> config setup
> plutorestartoncrash=false
> protostack=netkey
> plutodebug="all"
> # Note: works with either 10 or 32001, however must
> # be same on both machines.
> secctx-attr-type=32001
>
> conn labeled_test
> auto=start
> rekey=no
> authby=secret
> type=transport
> left=192.168.1.77
> right=192.168.1.64
> ike=3des-sha1
> phase2=esp
> phase2alg=aes-sha1
> labeled-ipsec=yes
> policy-label=system_u:object_r:ipsec_spd_t:s0
> leftprotoport=tcp
> rightprotoport=tcp
>
> I could see the correct peer context using getpeercon(3) on my test
> client/server:
> Server Peer Context: unconfined_u:unconfined_r:unconfined_t:s0-
> s0:c0.c1023
> Client Peer Context: unconfined_u:unconfined_r:unconfined_t:s0-
> s0:c0.c1023
>
> Hope you get yours to work now (or you may have it working already
> ??)
>
> Richard
7 years, 2 months
ipsec module and Libreswan on CentOS 7 denied
by Grzegorz Kuczyński
Hello
I configured Labeled IPSec on CentOS 7 using Libreswan and I found such
denied:
type=AVC msg=audit(1491053758.389:1366): avc: denied { polmatch } for
pid=0 comm="swapper/0" scontext=system_u:object_r:unlabeled_t:s0
tcontext=system_u:object_r:ipsec_spd_t:s0 tclass=association
My config file on both hosts is:
# cat /etc/ipsec.conf
version 2
config setup
protostack=netkey
conn ipsec_selinux_tunnel
...
labeled_ipsec=yes
policy_label=system_u:object_r:ipsec_spd_t:s0
It's looks like process swapper is missing labeled?
I must add this rule to my own module:
allow unlabeled_t ipsec_spd_t:association { polmatch };
This is not a bug?
7 years, 2 months
Re: SELinux is preventing boomagabackend from 'sys_ptrace' accesses on the cap_userns Unknown.
by Oleg Pykhalov
Lukas Vrabec <lvrabec(a)redhat.com> writes:
> On 03/31/2017 04:30 PM, Oleg Pykhalov wrote:
>>> On 03/30/2017 01:19 PM, Martin Gansser wrote:
>>> $ cat boomaga_local.cil
>>> (allow boomaga_cups_t boomaga_cups_t(cap_userns (sys_ptrace)))
>>>
>>> # semodule -i boomaga_local.cil
>>
>> Thank you for tip but I get another error. So I still have some delay
>> printing to boomaga printer.
>>
>> $ sudo semodule -l | grep boomaga
>> boomaga
>> boomaga_local
>>
>> $ cat boomaga_local.cil
>> (allow boomaga_cups_t boomaga_cups_t(cap_userns (sys_ptrace)))
>>
>> $ journalctl -b
>> Mar 31 17:08:31 magnolia.home.lan audit[1070]: USER_AVC pid=1070
>> uid=81 auid=4294967295 ses=4294967295
>> subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:
>> denied { send_msg } for msgtype=method_return dest=:1.1062 spid=1084
>> tpid=12021 scontext=system_u:system_r:systemd_logind_t:s0
>> tcontext=system_u:system_r:boomaga_cups_t:s0-s0:c0.c1023 tclass=dbus
>> exe="/usr/bin/dbus-daemon"
>> sauid=81 hostname=? addr=? terminal=?'
>>
>
> Update your boomaga_local.cil file:
> $ cat boomaga_local.cil
> (allow boomaga_cups_t boomaga_cups_t(cap_userns (sys_ptrace)))
> (allow systemd_logind_t boomaga_cups_t(dbus (send_msg)))
>
> and load it again:
> # semodule -i boomaga_local.cil
>
> Lukas.
>
> _______________________________________________
>> selinux mailing list -- selinux(a)lists.fedoraproject.org
>> To unsubscribe send an email to selinux-leave(a)lists.fedoraproject.org
>>
Thank you for supporting this issue. I got another bunch of errors, but
I tried to solve it myself.
$ journalctl -b
Apr 04 19:17:47 magnolia.home.lan audit[938]: USER_AVC pid=938 uid=81
auid=4294967295 ses=4294967295
subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied
{send_msg } for msgtype=method_call
interface=org.freedesktop.DBus.Introspectable member=Introspect
dest=org.freedesktop.login1 spid=5692 tpid=952
scontext=system_u:system_r:boomaga_cups_t:s0-s0:c0.c1023
tcontext=system_u:system_r:systemd_logind_t:s0 tclass=dbus
exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
$ cat boomaga_local.cil
(allow boomaga_cups_t boomaga_cups_t(cap_userns (sys_ptrace)))
(allow systemd_logind_t boomaga_cups_t(dbus (send_msg)))
(allow boomaga_cups_t systemd_logind_t(dbus (send_msg)))
$ sudo semodule -i boomaga_local.cil
$ journalctl -b
Apr 04 19:30:48 magnolia.home.lan dbus-daemon[1597]: avc: denied {
send_msg } for msgtype=method_call interface=org.boomaga member=add
dest=org.boomaga spid=6894 tpid=6852
scontext=system_u:system_r:boomaga_cups_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tclass=dbus
$ cat boomaga_local.cil
(allow boomaga_cups_t boomaga_cups_t(cap_userns (sys_ptrace)))
(allow systemd_logind_t boomaga_cups_t(dbus (send_msg)))
(allow boomaga_cups_t systemd_logind_t(dbus (send_msg)))
(allow boomaga_cups_t unconfined_t(dbus (send_msg)))
$ sudo semodule -i boomaga_local.cil
Printing to boomaga is working without errors and delays now.
7 years, 2 months
Re: ipsec module and Libreswan on CentOS 7 denied
by Stephen Smalley
On Tue, 2017-04-04 at 14:03 +0100, Richard Haines wrote:
> On Mon, 2017-04-03 at 14:49 -0400, Stephen Smalley wrote:
> > On Sun, 2017-04-02 at 11:57 +0200, Grzegorz Kuczyński wrote:
> > > Hello
> > > I configured Labeled IPSec on CentOS 7 using Libreswan and I
> > > found
> > > such denied:
> > >
> > > type=AVC msg=audit(1491053758.389:1366): avc: denied { polmatch
> > > }
> > > for pid=0 comm="swapper/0"
> > > scontext=system_u:object_r:unlabeled_t:s0
> > > tcontext=system_u:object_r:ipsec_spd_t:s0 tclass=association
> > >
> > > My config file on both hosts is:
> > >
> > > # cat /etc/ipsec.conf
> > > version 2
> > >
> > > config setup
> > > protostack=netkey
> > >
> > > conn ipsec_selinux_tunnel
> > > ...
> > > labeled_ipsec=yes
> > > policy_label=system_u:object_r:ipsec_spd_t:s0
>
> I have not tested this for a few years, however last time I did, I
> put
> the process context in policy_label= as at that time the man page had
> not been updated with the example it now has !!. Worth a try ??
If so, that seems like a bug in pluto; the pluto configuration should
only need to specify the policy security context; the SA security
context should be automatically derived from the context of the sender
that triggered the SA establishment.
>
> > >
> > > It's looks like process swapper is missing labeled?
> > >
> > > I must add this rule to my own module:
> > > allow unlabeled_t ipsec_spd_t:association { polmatch };
> > >
> > > This is not a bug?
> >
> > The unlabeled context is from the flow, not the process, for this
> > check. The current process is irrelevant, since this is happening
> > on
> > network input processing of the received packet. I guess the
> > question
> > is how did we end up with an unlabeled flow. What does 'ip xfrm
> > state'
> > show as the security context for the association?
> >
> > FWIW, there is a sample configuration of labeled IPSEC over
> > loopback
> > (and tests for it) in the selinux-testsuite. That however is a
> > manual
> > configuration.
> >
7 years, 2 months
SELinux is preventing boomagabackend from 'sys_ptrace' accesses on the
cap_userns Unknown.
by Martin Gansser
I have received this error report, about boomaga.
I can print to boomaga printer, but with a delay about 30 seconds per task. SELinux Troubleshooter reports an error.
SELinux is preventing boomagabackend from 'sys_ptrace' accesses on the cap_userns Unknown.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that boomagabackend should be allowed sys_ptrace access on the Unknown cap_userns 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:
# ausearch -c 'boomagabackend' --raw | audit2allow -M my-boomagabackend
# semodule -X 300 -i my-boomagabackend.pp
Additional Information:
Source Context system_u:system_r:boomaga_cups_t:s0-s0:c0.c1023
Target Context system_u:system_r:boomaga_cups_t:s0-s0:c0.c1023
Target Objects Unknown [ cap_userns ]
Source boomagabackend
Source Path boomagabackend
Port <Unknown>
Host (removed)
Source RPM Packages
Target RPM Packages
Policy RPM selinux-policy-3.13.1-225.11.fc25.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name (removed)
Platform Linux (removed) 4.9.14-200.fc25.x86_64 #1 SMP Mon
Mar 13 19:26:40 UTC 2017 x86_64 x86_64
Alert Count 3
First Seen 2017-03-25 00:29:09 MSK
Last Seen 2017-03-25 00:32:12 MSK
Local ID 531f80ea-deab-40c6-9bd0-c7375eef6639
Raw Audit Messages
type=AVC msg=audit(1490391132.808:798): avc: denied { sys_ptrace } for pid=12332 comm="boomagabackend" capability=19 scontext=system_u:system_r:boomaga_cups_t:s0-s0:c0.c1023 tcontext=system_u:system_r:boomaga_cups_t:s0-s0:c0.c1023 tclass=cap_userns permissive=1
Hash: boomagabackend,boomaga_cups_t,boomaga_cups_t,cap_userns,sys_ptrace
------------------------------------
Have someone a idea how can this be solved ?
The files of the package were stored for test purposes here: https://martinkg.fedorapeople.org/Review/test/boomaga/
7 years, 2 months
