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
3 years, 10 months
Re: RHEL 7 consoletype_exec interface issue
by Douglas Brown
Hi,
In RHEL 7 when using the userdom_unpriv_user_template interface to create a new role, it in turn uses the consoletype_exec interface; but when I attempt to insert a policy compiled with this, it says the type consoletype_exec_t doesn’t exist.
N.B. This works on RHEL 6.
Thanks,
Doug
6 years, 2 months
user based access control
by Jeff Becker
Hi. I successfully compiled and loaded the following policy file on RHEL7
with the latest (as of yesterday) SELinux rpms. However, when I run "seinfo
-tfoo_t -x", I don't see ubac_constrained_type listed in the attributes.
How do I enable UBAC? Thanks.
-jeff
--------------------------------------------------------------------------------------------------------------------------------------------------------------
policy_module(foo, 1.0.0)
########################################
#
# Declarations
#
userdom_unpriv_user_template(foo)
########################################
#
# foo local policy
#
domain_use_interactive_fds(foo_t)
files_read_etc_files(foo_t)
miscfiles_read_localization(foo_t)
ubac_constrained(foo_t)
6 years, 6 months
Re: Determine SELinux domain of daemon which isn't running
by Gary Tierney
On Sat, Nov 19, 2016 at 11:35:38PM -0600, Leroy Tennison wrote:
>Thanks, this explained some missing background which is great. I
>combined your instructions and ran 'sesearch -CST -s init_t -t
>rsync_exec_t -c process' after 'ls -laZ /usr/bin/rsync' to get:
>
>Found 1 semantic te rules:
> type_transition init_t rsync_exec_t : process rsync_t;
>
>but, as I replied earlier, running 'ps -eZ | grep rsync' after running
>'rsync --daemon' produced:
>unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 2575 ? 00:00:00
>rsync
>
>when I was expecting to see rsync somewhere in the response. Is this
>due to my setup: enforcing with targeted policy? (BTW, this is
>CentOS7 with default SELinux so MLS is enabled, policy deny_unknown
>status is allowed and max kernel policy version is 28).
>
This is because you are executing rsync from a shell, which has a
different context from systemd and thus different applicable
type_transition rules.
If we instead use runcon to execute rsync in the domain it would have
been executed in if systemd launched it by doing this:
$ runcon "system_u:system_r:rsync_t:s0" /usr/bin/rsync $HOME/dir1 $HOME/dir2
We can see some AVCs from the newly launched rsync process trying to
copy those files:
# ausearch -i -m AVC -ts recent
----
type=AVC msg=audit(20/11/16 16:51:00.227:298) : avc: denied { search } for pid=1166 comm=rsync name=gtierney dev="dm-6" ino=131073 scontext=system_u:system_r:rsync_t:s0 tcontext=unconfined_u:object_r:user_home_t
dir_t:s0 tclass=dir permissive=0
----
>Maybe I should mention what I'm trying to do and someone will have an
>alternative. I'm trying to gain experience working with SELinux by
>having a daemon attempt to access a file that SELinux prohibits and
>then resolve the issue by relabeling it. I was also wanting to avoid
>setting up something complicated (like Apache) just for a test. I
>thought rsync would be easy but am discovering otherwise.
>
The main problem for that is you are executing programs from your
unconfined shell. If you were to create a service unit for the rsync
daemon you will likely see better results.
The SELinux manpage for rsync gives some more information on how to
configure rsync to access files with SELinux when you have it running in
the correct domain: https://fedoraproject.org/wiki/SELinux/rsync
>On 11/18/2016 08:30 PM, Gary Tierney wrote:
>>On Fri, Nov 18, 2016 at 04:26:45AM -0000, leroy.tennison(a)verizon.net
>>wrote:
>>>I just beginning to learn SELinux and have numerous questions
>>>(I've read roughly half of the "Red Hat Enterprise Linux 7 SELinux
>>>User's and Administrator's Guide"). The first one is how to
>>>determine the domain of a daemon if it isn't running. If there's
>>>documentation on this and I've just missed it just point me to it.
>>>Thanks for your help.
>>>__
>>
>>Hi,
>>
>>The context of a process usually depends on the domain which started
>>it. In Fedora's current policy systemd runs as init_t, so to find
>>out what the context of a daemon it starts would be we need to look
>>for type_transition rules with init_t as the source type. You can
>>do this by using sesearch from setools-console:
>>
>>$ sesearch -CST -s init_t -c process
>>Found 721 semantic te rules:
>> type_transition init_t cgconfig_exec_t : process cgconfig_t;
>> type_transition init_t deltacloudd_exec_t : process deltacloudd_t;
>> ... snip ...
>>
>>The target type in these rules is the type of the programs
>>executable file, so to filter the sesearch results to a single
>>program we can do this:
>>
>>$ ls -laZ /sbin/dnsmasq
>>-rwxr-xr-x. 1 root root system_u:object_r:dnsmasq_exec_t:s0 373928
>>Jul 15 13:57 /sbin/dnsmasq
>>
>>$ sesearch -CST -s init_t -t dnsmasq_exec_t -c process
>>Found 1 semantic te rules:
>> type_transition init_t dnsmasq_exec_t : process dnsmasq_t;
>>
>>So we know that when init_t execve()'s a program with a type of
>>dnsmasq_exec_t it will transition to dnsmasq_t [1]. You can also
>>achieve the same result by using selinuxexeccon from
>>libselinux-utils:
>>
>>$ selinuxexeccon /usr/sbin/dnsmasq "system_u:system_r:init_t:s0"
>>system_u:system_r:dnsmasq_t:s0
>>
>>[1] - A process can also call setexeccon() to set the context for a
>>new process before it calls execve().
>>_____________________________________________
>>>selinux mailing list -- selinux(a)lists.fedoraproject.org
>>>To unsubscribe send an email to selinux-leave(a)lists.fedoraproject.org
>>
>>
>>
>>_______________________________________________
>>selinux mailing list -- selinux(a)lists.fedoraproject.org
>>To unsubscribe send an email to selinux-leave(a)lists.fedoraproject.org
>
--
Gary Tierney
GPG fingerprint: 412C 0EF9 C305 68E6 B660BDAF 706E D765 85AA 79D8
https://sks-keyservers.net/pks/lookup?op=get&search=0x706ED76585AA79D8
6 years, 6 months
Questions about restricted users
by Leroy Tennison
According to
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/...
(Table 3.1), guest_u can't use networking. What does this mean, regular
users on non-SELinux systems can't modify network parameters?
There are a few non-integrated aspects surrounding restricted users,
wondering if this is going to be rectified in the future or is there an
underlying reason it was done? Examples:
User deletion doesn't automatically remove any SELinux definition for
that user. I experimented enough to learn that, if a user is deleted
without removing the SELinux context and later a user with the same name
is created then it will automatically have the previously-defined
SELinux context. I saw the warnings when using useradd and userdel but
wondered why the process wasn't just integrated.
Changing a user to be restricted also requires using 'chcon -R' on their
home directory, is there a reason this isn't integrated?
If a user is made restricted and root then does 'su - <user>', 'id -Z'
doesn't report the restricted context even though whoami reports the
restricted user name. Is this "by design"?
6 years, 6 months
Determine SELinux domain of daemon which isn't running
by Leroy Tennison
I just beginning to learn SELinux and have numerous questions (I've read roughly half of the "Red Hat Enterprise Linux 7 SELinux User's and Administrator's Guide"). The first one is how to determine the domain of a daemon if it isn't running. If there's documentation on this and I've just missed it just point me to it. Thanks for your help.
6 years, 6 months
Build SELinux policy
by Jeff Becker
Hi. I have selinux-policy-3.13.1-102.el7_3.4.src.rpm. After installing it,
I ran rpmbuild -bt to set up the BUILD directory. In
BUILD/serefpolicy-3.13.1/, I edited build.conf to specify UBAC=y and name
my policy targeted-ubac. I then ran "make conf;make install-src". I then cd
to /etc/selinux/targeted-ubac/src/policy, and ran "make load". I get the
following error.
Creating targeted-ubac base module base.conf
cat tmp/pre_te_files.conf tmp/all_attrs_types.conf tmp/global_bools.conf
tmp/only_te_rules.conf tmp/all_post.conf > base.conf
Compiling targeted-ubac base module
/usr/bin/checkmodule -M -U allow base.conf -o tmp/base.mod
/usr/bin/checkmodule: loading policy configuration from base.conf
policy/modules/kernel/domain.te:285:ERROR 'unknown type tape_device_t used
in transition definition' at token ';' on line 26087:
type_transition named_filetrans_domain device_t:chr_file tape_device_t
"ht00";
I can see tape_device_t in policy/modules/kernel/storage.te, so I'm not
sure what the problem is. Any advice appreciated. Thanks.
-jeff
6 years, 6 months
Policy module versioning
by Steve Huston
In the last few days I've upgraded a couple test systems to RHEL 7.3,
and with that came a new version of policycoreutils (named 2.5-9.el7,
up from 2.2.5-20). I found where some time ago the 'semodule' command
was modified to remove the version information from the output, which
has an unintended side effect of breaking my puppet modules that
maintain local selinux modules and verify the version running is equal
to the one in the manifest. The comment in the checkin (e599a4)
states that CIL does not have a concept of versions, so it's being
removed.
My question is, what is a good way to determine that the module that
is installed and running matches the one in a specific .te file? I
could of course tell puppet to trigger a rebuild of the .pp file if
the .te has been modified, but it seems without rebuilding and/or
reinstalling every puppet run there's no good way to verify that the
version in memory is the one I've intended.
--
Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci
Princeton University | ICBM Address: 40.346344 -74.652242
345 Lewis Library |"On my ship, the Rocinante, wheeling through
Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus,
(267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1'
6 years, 6 months
how to assign process to user
by Naina Emmanuel
Good afternoon!
How to we can any process permission to any specific user ?
As processes run with the privileges of user under which they are
running....
do we have any policy module for that?
thanks
*Engr. Naina Emmanuel*
*Cryptography Certified*
*Linux Essential Certified (LEPDC)*
*Cisco Certified Network Associate (CCNA)*
*Computer Engineering Department, UET Taxila*
*Information Security, CS Department, CIIT Islamabad*
6 years, 6 months
allow rules for CTDB <=> Samba (or booleans?)
by lejeczek
hi everyone
I'm seeing there is some issues when one wants ctdb to
control Samba.
Do we have booleans or maybe somebody has a complete set of
rules?
I see (at least):
#============= ctdbd_t ==============
allow ctdbd_t cupsd_etc_t:dir getattr;
#!!!! This avc is allowed in the current policy
allow ctdbd_t kernel_t:system module_request;
allow ctdbd_t kmsg_device_t:chr_file { write open };
allow ctdbd_t samba_etc_t:lnk_file read;
allow ctdbd_t samba_spool_t:dir { getattr search };
#============= samba_net_t ==============
allow samba_net_t fusefs_t:file { read getattr open };
allow samba_net_t samba_etc_t:lnk_file read;
#============= smbd_t ==============
#!!!! This avc is allowed in the current policy
allow smbd_t cupsd_etc_t:dir { write create add_name };
#!!!! This avc is allowed in the current policy
allow smbd_t samba_etc_t:lnk_file read;
and I worry I am not missing some boolean.
thx.
L.
6 years, 6 months
