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, 4 months
[HEADS UP] Default value of SELinux boolean httpd_graceful_shutdown
will changed.
by Lukas Vrabec
I'm planning change the default value of httpd_graceful_shutdown boolean
in Fedora Rawhide because of improving SELinux configuration. Rawhide
builds with this change will be available in ~5 days.
Together with Dan Walsh, we agreed on that httpd_graceful_shutdown
boolean should be by default turned off. This boolean allows HTTPD to
connect to port 80 for graceful shutdown, but it's breaking the
functionality of another boolean called: httpd_can_network_connect. This
boolean allows HTTPD scripts and modules to connect to the network using
TCP and it's turned off by default.
Turning this boolean off can cause some troubles, on web-servers where
processes with httpd_t SELinux domain connecting to tcp ports: 80, 81,
443, 488, 8008, 8009, 8443, 9000
If you would like to turn in on again, use semanage command:
# semanage boolean -m --on httpd_graceful_shutdown
If you have any questions, feel free to contact me.
Lukas.
--
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.
6 years, 2 months
Re: [HEADS UP] Default value of SELinux boolean
httpd_graceful_shutdown will changed.
by Lukas Vrabec
On 09/29/2017 03:57 PM, Alexander Bokovoy wrote:
> On pe, 29 syys 2017, Lukas Vrabec wrote:
>> I'm planning change the default value of httpd_graceful_shutdown
>> boolean in Fedora Rawhide because of improving SELinux configuration.
>> Rawhide builds with this change will be available in ~5 days.
>>
>> Together with Dan Walsh, we agreed on that httpd_graceful_shutdown
>> boolean should be by default turned off. This boolean allows HTTPD to
>> connect to port 80 for graceful shutdown, but it's breaking the
>> functionality of another boolean called: httpd_can_network_connect.
>> This boolean allows HTTPD scripts and modules to connect to the
>> network using TCP and it's turned off by default.
>>
>> Turning this boolean off can cause some troubles, on web-servers where
>> processes with httpd_t SELinux domain connecting to tcp ports: 80, 81,
>> 443, 488, 8008, 8009, 8443, 9000
>>
>> If you would like to turn in on again, use semanage command:
>> # semanage boolean -m --on httpd_graceful_shutdown
> In FreeIPA we have httpd_can_network_connect enabled. I just checked a F26
> system and I have both booleans enabled.
>
> # getsebool -a|egrep 'httpd_graceful_shutdown|httpd_can_network_connect '
> httpd_can_network_connect --> on
> httpd_graceful_shutdown --> on
>
> So I'm a bit confused: disabling httpd_graceful_shutdown will have or
> wouldn't have an effect on httpd_can_network_connect being enabled?
>
httpd_graceful_shutdown is subset of httpd_can_network_connect.
Turning on httpd_graceful_shutdown you allow httpd_t domain connecting
just to ports labeled as httpd_port_t.
Turning on httpd_can_network_connect you allow httpd_t domain connecting
to all ports from SELinux POV.
Right now, we ship selinux-policy with httpd_graceful_shutdown turned on
and httpd_can_network_connect turned off. But it's confusing for users
because they have httpd_can_connect turned off but httpd_t domain can
still connect co http_port_t ports becuase of httpd_gracefull_shudown.
I hope it's more clear now.
> Do I need to do anything in FreeIPA setup?
>
No if httpd_can_network_connect is enabled during FreeIPA setup, you
don't need to change anything.
Lukas.
--
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.
6 years, 2 months
Re: Unable to use audit2allow on avc denials
by birdynam
Yep your right,
i just wanted to point the fact that even if the logs are in messages
instead of audit.log, audit2allow can be used (related to Wilkinson
Matthew post).
Birdy.
6 years, 2 months
Unable to use audit2allow on avc denials
by Wilkinson, Matthew
Has anyone seen SELinux log to /var/log/messages but *not* to /var/log/audit/audit.log? I have a situation that is being denied by SELinux and logging avc denials to /var/log/messages, however I can't determine a way to fix it because I get nothing for this denial logged to /var/log/audit/audit.log. This prevents me from generating a policy using audit2allow or sealert.
Situation: I have a RHEL 7-based server which is running bind-chroot and I'd like for rsyslog to collect and send the named.log and query.log to our centralized rsyslog server. With SELinux in enforcing mode, rsyslog cannot read the named logs.
Do I need to write my own custom SELinux policy?
Thanks,
Matthew Wilkinson
6 years, 2 months
does order in/of fcontext rules matter?
by lejeczek
hi
I did not know, but it seems that "order" matters.
Would there be a doc, howto or maybe a man page that
explains importance of the order in which rules(maybe only
local) appear, are processed?
if I have something like:
$ semanage fcontext -lC
....
/__.aLocalStorages/0/0-SUBVERSIONs(/.*)?/db(/.*)? all
files system_u:object_r:httpd_sys_rw_content_t:s0
/__.aLocalStorages/0/0-SUBVERSIONs(/.*)?/locks(/.*)? all
files system_u:object_r:httpd_sys_rw_content_t:s0
/__.aLocalStorages/0/0-SUBVERSIONs(/.*)? all
files system_u:object_r:httpd_sys_content_t:s0
then:
$ /__.aLocalStorages/0/0-SUBVERSIONs/myRepo/locks will not
get "httpd_sys_rw_content_t"
but I put/add them so they would be:
/__.aLocalStorages/0/0-SUBVERSIONs(/.*)? all
files system_u:object_r:httpd_sys_content_t:s0
/__.aLocalStorages/0/0-SUBVERSIONs(/.*)?/db(/.*)? all
files system_u:object_r:httpd_sys_rw_content_t:s0
/__.aLocalStorages/0/0-SUBVERSIONs(/.*)?/locks(/.*)? all
files system_u:object_r:httpd_sys_rw_content_t:s0
then yes, /__.aLocalStorages/0/0-SUBVERSIONs/myRepo/locks
will get "httpd_sys_rw_content_t"
I'd expect such a crucial fact would be in *bold* in man
pages, but I cannot find it @centos 7.x.
.
6 years, 2 months
usbguard policy
by Thomas Mueller
hi
I could not find a usbguard policy altough the service runs as root.
I've created an initial policy to confine the usbguard daemon:
https://github.com/fedora-selinux/selinux-policy-contrib/pull/26/files
I encountered some problems:
* the daemon wants to manage it's usbguard-daemon.conf file. If the
usbguard-daemon process has no write access to /etc/usbguard-daemon.conf
it will quit immediately on service start. At least for servers I wan't
to manage the config with a config mgmt tool and not let usbguard itself
change it's config.
* server vs. desktop: the daemon provides an interface for desktop
applets or the usbuard cli to manipulate the rules and config. This is
desirable for a desktop but IMHO not for servers. what should be the
default? should the daemon be allowed to change its config/rules or not?
- Thomas
https://dkopecek.github.io/usbguard/
6 years, 3 months
