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, 1 month
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
Removing unnecessary dac_override capability
by Lukas Vrabec
Hi SELinux list,
Some weeks ago was introduced patch swapping hooks for dac_override /
dac_read_search capabilities. This allow us to remove some unnecessary
dac_override rules and tighten security in Fedora.
In Fedora, every domain with dac_override capability has also
dac_read_search capability to fix AVCs.
Workflow for removing unnecessary is quite simple. I created scratch
build with no dac_override capability. Right now, I'm trying to use this
build on Rawhide and collecting AVCs. After fixing AVCs collected by me,
I'll try to push it to Fedora Rawhide builds (after discussion with Adam
Williamson and Fedora devel list)
If you're interested, feel free to help me with collecting AVCs. Here is
the link with scratch builds:
https://copr.fedorainfracloud.org/coprs/lvrabec/selinux-policy-dac/
Thanks,
Lukas.
--
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.
6 years
Confined user fedora 26
by birdynam
Hello,
after creation of a new user, i tried to confined him to user_u selinux
user.
I applied semanage -a -s user_u newuser. Then logout.
After that i can not log to any of my users from gnome and have to
reboot the workstation (under vbox).
Then the only thing i can do is to log to root and unconfined my newuser.
I was able to log into root user only if it is the first attempt to log,
ie if i tried an other user before, i have to reboot again.
No selinux avc is log.
birdynam,
Thanks,
6 years, 1 month
