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, 7 months
SELinux on a diskless client
by Göran Uddeborg
Hello,
Could anyone advice on how to make SELinux run on a diskless client
with NFS root?
It is a Fedora 26 system. I'm mounting with NFS flags to enable
SELinux labels.
... root=nfs4:mimmi:/remote/pluto,seclabel,vers=4.2 rootfstype=nfs4
rootflags=seclabel,vers=4.2 ...
(I guess I'm duplicating things here. Google have found different
suggestions in different places. I've added all of them for now.)
Listing directories after the system comes up shows all labels as
expected. For example
[goeran@pluto ~]$ ls -lZ /usr/lib/systemd/systemd
-rwxr-xr-x. 1 root root system_u:object_r:init_exec_t:s0 1183248 27 jun 23.49 /usr/lib/systemd/systemd
But the processes don't wind up in the correct domains. Process 1
remains in kernel_t. A lot of other processes too, but I guess the
underlying reason is process 1.
[goeran@pluto ~]$ ps -Zp 1
LABEL PID TTY TIME CMD
system_u:system_r:kernel_t:s0 1 ? 00:00:24 systemd
The only exception is when I login via SSH. Those processes wind up
in the unconfined_t domain. SSHD seems to still do the right thing,
and from there it appears to work. E.g. if I start a dbus-daemon in
the SSH session, it runs in unconfined_dbusd_t.
I run this system in permissive mode, so things do work. But I
naturally do get a lot of AVCs. Of course, I would prefer to make
SELinux enforced if possible.
Anyone has any tips?
6 years, 4 months
maximum excludes workaround?
by Wart
OS: SL7.3, policycoreutils-2.5-11.el7_3.x86_64
I have a cluster with quite a few user home directories automounted from
a NFS server. I have found that if too many (> ~1000) home directories
are mounted, restorecon spits out the following:
# restorecon -R /var/lib/boinc
Maximum excludes 1000 exceeded.
[repeats hundreds of times]
This message pops up even when I'm not relabeling a part of the
filesystem that's unmounted. If I reduce the number of automounted home
directories, then the message goes away.
I get similar messages when loading and unloading custom selinux policy
modules.
Will this actually prevent restorecon from relabeling files?
Is there a dynamic way to increase this limit to make the messages go away?
--Wart
6 years, 4 months
pre-labeling a file system for embedded device
by Nathan Owen
Hi,
As a disclaimer, I am very new to SELinux policy development.
My team and I are responsible for software architecture on an embedded (red hat) system. We pre-build the file system and save it to a squashfs that is then burned to the device. The result of this is that the system is, for the most part, read-only.
The problem is that we would like to start using SElinux, but we do not know if there is a way we can pre-label the files before saving them to the squashfs. We cannot label them at runtime as the file system is read only.
Does any one know if there is a way to pre-label an embedded linux file system from a development computer that does not have the same SElinux policies as the embedded platform?
Thank you,
Nathan Owen
6 years, 5 months
winbind missing selinux policy in fed 27?
by Lin Pro
Hi,
I was wondering if winbind package has a default policy included in Fedora 27?
In permissive mode it works as below:
winbind.service - Samba Winbind Daemon
Loaded: loaded (/usr/lib/systemd/system/winbind.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2017-10-03 08:16:09 CDT; 5h 17min ago
Main PID: 1009 (winbindd)
Status: "winbindd: ready to serve connections..."
Tasks: 4 (limit: 4915)
CGroup: /system.slice/winbind.service
├─1009 /usr/sbin/winbindd
├─1010 /usr/sbin/winbindd
├─1066 /usr/sbin/winbindd
└─1068 /usr/sbin/winbindd
But in Enforcing Mode does not:
[root@fedmember1 ~]# systemctl stop winbind
[root@fedmember1 ~]# setenforce 1
[root@fedmember1 ~]# systemctl start winbind
Job for winbind.service failed because the control process exited with error code.
See "systemctl status winbind.service" and "journalctl -xe" for details.
Oct 03 08:07:20 fedmember1 winbindd[685]: tdb(/var/lib/samba/private/netlogon_creds_cli.tdb): tdb_open_ex: tdb_new_database failed for /var/lib/samba/private/netlogon_creds_cli.tdb: Permission denied
Oct 03 08:07:20 fedmember1 winbindd[685]: [2017/10/03 08:07:20.664239, 0] ../lib/tdb_wrap/tdb_wrap.c:64(tdb_wrap_log)
Oct 03 08:07:20 fedmember1 audit[685]: AVC avc: denied { map } for pid=685 comm="winbindd" path="/var/lib/samba/private/netlogon_creds_cli.tdb" dev="dm-0" ino=137059 scontext=system_u:system_r:winbind_t:s0 tcontext=unconfined_u:object_r:samba_var_t:s0 tclass=file permissive=0
Oct 03 08:07:20 fedmember1 audit[685]: AVC avc: denied { map } for pid=685 comm="winbindd" path="/var/lib/samba/private/secrets.tdb" dev="dm-0" ino=137051 scontext=system_u:system_r:winbind_t:s0 tcontext=unconfined_u:object_r:samba_var_t:s0 tclass=file permissive=0
Oct 03 08:07:20 fedmember1 audit[685]: AVC avc: denied { map } for pid=685 comm="winbindd" path="/var/lib/samba/lock/names.tdb" dev="dm-0" ino=137022 scontext=system_u:system_r:winbind_t:s0 tcontext=unconfined_u:object_r:samba_var_t:s0 tclass=file permissive=0
Any hints are welcome how to fix it
Thank you
Lin
6 years, 5 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, 5 months