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, 8 months
Puzzle involving sudo_role_template, shell script context,
file type in /tmp
by Lou Hafer
Folks,
I have a problem with SEL file type in /tmp --- I just don't understand why a particular type is being used. More precisely, I don't understand how the domain that uses this file type comes into play. I'm hoping someone can enlighten me.
I have a setup where subversion is accessed through httpd (mod_dav_svn). The post-commit hook runs as the confined uid apache. The hook needs to do bookkeeping using a different confined uid, coin. I've implemented a custom SEL module svn_hook, to allow this. It uses the sudo_role_template macro as part of the setup. The full domain transition sequence to get to the sudo'd script is:
* Domain httpd_t transitions through type svn_hook_exec_t to domain svn_hook_t when the top-level hook script is
executed
* User changes from apache to coin by sudo'ing a second-level script. The expected domain transition would be
svn_hook_t -> svn_hook_sudo_t -> svn_hook_t. (Perhaps I'm wrong on this?)
When I run 'id' in the second-level script, it says the context is
uid=1002(coin) gid=1013(coin-web) context=system_u:system_r:svn_hook_t:s0
as expected. Elsewhere in the SEL module, svn_hook_t is granted full file and directory management rights in /tmp with the files_manage_generic_tmp_{dirs,files} macros. When I run, for example, 'svn export' in this script, it happily creates entire directory trees of type tmp_t in /tmp, as expected.
But ... if I try to redirect output to a file, or execute something like 'touch foo', the type used for file creation is svn_hook_sudo_tmp_t (generated within the sudo_role_template macro). I've opened this macro up, and I can see it will create the rule 'type_transition svn_hook_sudo_t tmp_t:file svn_hook_sudo_tmp_t;' Fine, I understand. And I've managed to deal with the issue by allowing domain svn_hook_t to manage files of type svn_hook_sudo_tmp_t.
What I don't understand: Why is domain svn_hook_sudo_t in play here? According to id, the script is running in domain svn_hook_t. If anyone can enlighten me on what's happening here, I'd be a much happier person.
Thanks,
Lou
7 years, 9 months
Unable for crond to load a root crontab on Fedora 23
by Lester M Petrie
Hi
I am running Fedora 23 in enforcing mode, and crond is not loading a root crontab when it is saved by
crontab -e. The journal shows the following message when I try to install it.
crond[1594]: (root) FAILED (loading cron table)
crond[1594]: (root) Unauthorized SELinux context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=unconfined_u:object_r:user_cron_spool_t:s0 (/var/spool/cron/root)
There doesn't appear to be any AVC message for this. Does anyone have any suggestions how to fix this.
Thanks.
--
Lester M Petrie
Bldg 5700, Room O305
Oak Ridge National Laboratory
Phone 865-574-5259, Email petrielmjr(a)ornl.gov
7 years, 10 months
Still getting an AVC
by David Highley
We had previously posted about this AVC and understood in a reply that
it was fixed in the next update but we're still seeing it once a day.
time->Fri Jan 15 03:22:01 2016
type=AVC msg=audit(1452856921.601:1934): avc: denied { read } for
pid=6439 comm="mdadm"
name="RstSataV-193dfefa-a445-4302-99d8-ef3aad1a04c6" dev="efivarfs"
ino=126 scontext=system_u:system_r:mdadm_t:s0-s0:c0.c1023
tcontext=system_u:object_r:efivarfs_t:s0 tclass=file permissive=0
It had been said that it was related to the secure boot process but all
of our systems use that and only one system is reporting this AVC.
7 years, 10 months
RE: Automatic type assignment to sysadm_t userdomain
by RIJKEN Jeroen
Dear Phil,
I tried your solution and it seemed to work initially, however the domain does not transition properly and the application crashes. The problem is, I don’t get any AVC error messages, not even when I disable dontaudit rules within the policy with ‘semodule -DB’. So I can’t troubleshoot the issue.
I guess I will just have to enable the script during bootup and restart the server to see if it loads properly. The problem is, since it’s a server, booting up takes such a long time ;)
Jeroen
From: Philip Seeley [mailto:pseeley@au1.ibm.com]
Sent: donderdag 14 januari 2016 23:31
To: RIJKEN Jeroen
Cc: 'selinux(a)lists.fedoraproject.org'
Subject: Re: Automatic type assignment to sysadm_t userdomain
Hi Jeroen,
For part 2 have you tried the "run_init" command?
Phil
------------------------------------------------------------------------------------------------------------
Disclaimer:
If you are not the intended recipient of this email, please notify the sender and
delete it.
Any unauthorized copying, disclosure or distribution of this email or its
attachment(s) is forbidden.
Thales Nederland BV will not accept liability for any damage caused by this email or
its attachment(s).
Thales Nederland BV is seated in Hengelo and is registered at the Chamber of
Commerce under number 06061578.
------------------------------------------------------------------------------------------------------------
7 years, 10 months
Automatic type assignment to sysadm_t userdomain
by RIJKEN Jeroen
Dear all,
This is a two-part question.
Part 1:
I have created multiple policies for various application, all type names begin with 'thales'. All the types specified are automatically assigned to the sysadm_t domain, I can verify this by running the following command:
sesearch --allow -R -s sysadm_t -t thales
A couple of questions:
Why is this necessary?
Is this done during compilation? What policy creates these rules?
Why are these types not automatically assigned to the staff_t, or any other type for that matter?
Part 2:
runcon -u system_u -r system_r -t initrc_t sh /path/to/executable
I need to simulate executing a script by the init system because that script usually gets started during startup by a command defined in rc.local. Otherwise I need to keep rebooting to test my policies. When I run the 'runcon' command while logged in as root and while running with the sysadm_r role and sysadm_t type I get the following AVC error:
----
time->Thu Jan 14 14:23:31 2016
type=PATH msg=audit(1452781411.076:7079): item=0 name="/bin/sh" inode=390152 dev=08:02 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:shell_exec_t
type=CWD msg=audit(1452781411.076:7079): cwd="/target/software"
type=SYSCALL msg=audit(1452781411.076:7079): arch=c000003e syscall=59 success=no exit=-13 a0=7fffbb439504 a1=7fffbb439740 a2=7fffbb439760 a3=352687dea0 items=1 ppid=21810 pid=22765 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=66 comm="runcon" exe="/usr/bin/runcon" subj=root:sysadm_r:sysadm_t key=(null)
type=AVC msg=audit(1452781411.076:7079): avc: denied { transition } for pid=22765 comm="runcon" path="/bin/bash" dev=sda2 ino=390152 scontext=root:sysadm_r:sysadm_t tcontext=system_u:system_r:initrc_t tclass=process
When running in permissive mode the transition happens with no problems, when running in enforcing mode I get a 'execvp: Permission denied' error message.
Is the sysadm_t not allowed to transition to initrc_t? How can I solve this issue? I need this script to run under the initrc_t domain. And the script is in a folder only the sysadm_t is allowed, because of the problem described in part 1.
Thanks in advance,
Jeroen
------------------------------------------------------------------------------------------------------------
Disclaimer:
If you are not the intended recipient of this email, please notify the sender and
delete it.
Any unauthorized copying, disclosure or distribution of this email or its
attachment(s) is forbidden.
Thales Nederland BV will not accept liability for any damage caused by this email or
its attachment(s).
Thales Nederland BV is seated in Hengelo and is registered at the Chamber of
Commerce under number 06061578.
------------------------------------------------------------------------------------------------------------
7 years, 10 months
execmem denial after going from RHEL7.1 -> 7.2
by Magnus Johansson
Hi,
We are seeing a problem in CentOS 7.2 that was not present in CentOS
7.1. We have program, suexec, that is pretty much a sudo replacement,
and it's run in a confined domain. It can be configured to authenticate
via SecurID, and does so by executing a separate binary, "securid". In
7.2 we get the following AVC when in enforcing mode:
type=AVC msg=audit(1452293979.299:489): avc: denied { execmem } for
pid=24801 comm="securid"
scontext=unconfined_u:unconfined_r:boks_suexec_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:boks_suexec_t:s0-s0:c0.c1023
tclass=process
type=SYSCALL msg=audit(1452293979.299:489): arch=c000003e syscall=59
per=400000 success=no exit=-13 a0=11db130 a1=7ffd15db7000 a2=11da350
a3=7ffd15db8df0 items=0 ppid=24800 pid=24801 auid=0 uid=0 gid=1000
euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=23
comm="securid" exe="/opt/boksm/lib/securid"
subj=unconfined_u:unconfined_r:boks_suexec_t:s0-s0:c0.c1023 key=(null)
This does not happen in 7.1 (or 7.0). There everything works just fine
with exactly the same binaries (built on RHEL 7.0), and there are no AVCs.
In permissive mode we get more AVCs:
type=AVC msg=audit(1452294353.555:498): avc: denied { execmem } for
pid=24891 comm="securid"
scontext=unconfined_u:unconfined_r:boks_suexec_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:boks_suexec_t:s0-s0:c0.c1023
tclass=process
type=SYSCALL msg=audit(1452294353.555:498): arch=c000003e syscall=59
per=400000 success=yes exit=0 a0=1114130 a1=7ffe8913bbe0 a2=1113350
a3=7ffe8913d9d0 items=0 ppid=24890 pid=24891 auid=0 uid=0 gid=1000
euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=23
comm="securid" exe="/opt/boksm/lib/securid"
subj=unconfined_u:unconfined_r:boks_suexec_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1452294353.555:499): avc: denied { execute } for
pid=24891 comm="securid" path="/etc/ld.so.cache" dev="dm-0" ino=17727429
scontext=unconfined_u:unconfined_r:boks_suexec_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:ld_so_cache_t:s0 tclass=file
type=SYSCALL msg=audit(1452294353.555:499): arch=c000003e syscall=9
per=400000 success=yes exit=140205884448768 a0=0 a1=50ed a2=1 a3=2
items=0 ppid=24890 pid=24891 auid=0 uid=0 gid=1000 euid=0 suid=0 fsuid=0
egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=23 comm="securid"
exe="/opt/boksm/lib/securid"
subj=unconfined_u:unconfined_r:boks_suexec_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1452294353.576:500): avc: denied { execute } for
pid=24891 comm="securid"
path=2F535953563030303030303030202864656C6574656429 dev="tmpfs"
ino=5570563
scontext=unconfined_u:unconfined_r:boks_suexec_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:tmpfs_t:s0 tclass=file
type=SYSCALL msg=audit(1452294353.576:500): arch=c000003e syscall=30
per=400000 success=yes exit=140205884469248 a0=550003 a1=0 a2=0
a3=7ffff48f38f0 items=0 ppid=24890 pid=24891 auid=0 uid=0 gid=1000
euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=23
comm="securid" exe="/opt/boksm/lib/securid"
subj=unconfined_u:unconfined_r:boks_suexec_t:s0-s0:c0.c1023 key=(null)
What is happening here? I do not know what to make of this.
Investigating this further reveals that not a single line from the
securid binary is run. It seems the AVC occurs during dynamic linking.
Why is it trying to execute ld.so.cache? Right now this strikes me as a
regression going from RHEL 7.1 -> RHEL 7.2, but I fail to pinpoint the
problem. This is all very strange to me, and I haven't seen similar AVCs
before.
Any thoughts?
Thanks,
Magnus
--
*Magnus Johansson*
Awesome Programmer
www.foxt.com <http://www.foxt.com/> | magnus.johansson(a)foxt.com
<mailto:magnus.johansson@foxt.com> | +46 73 363 00 60
Connect with me on Linkedin
<https://se.linkedin.com/in/magnus-johansson-37332525>
7 years, 11 months
How can I restrict a port to only a process?
by Andrei Cristian Petcu
Hello,
Not sure if this is the best place for n00b questions but here we go:
How can I restrict a port to only a process?
Let's say I have FOO process that wants to listen to port 2345 and no
other process on the machine to listen to it. Is it possible? The way I
see it is that unconfined processes would still have access to that
port, right?
My actual problem is that I want to make a mutual TLS connection between
2 unsecured apps that I am not a developer of. The apps (client/server)
use a TCP based protocol that is not text based or related to HTTP. So I
start a TLS tunel with stunel that listens to 2345 on localhost and
forwards it to remote_machine port 2345. I want to be certain that other
process can connect to localhost:2345 except my FOO process.
foo_process ---> localhost:2345 ===> remote_machine:2345
---> is insecure and I want to restrict
===> is mutual TLS over the network
Is this possible? Is this a good solution?
Thank you,
Andrei Petcu
7 years, 11 months
Were does the desktop background information get stored?
by Jean-David Beyer
I am running Red Hat Enterprise Linux 6 and I can easily change the look
of the desktop by right clicking on an empty part of the desktop and
selecting Change Desktop Background.
I would like to be able to have a cron script change the image displayed
depending on the time and day of the week. That would be easy if I knew
where the information is stored. But I do not know where that is.
If I click Help on that screen, it brings up a window that may have the
information, but it crashes very fast before I can read it.
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key:166D840A 0C610C8B Registered Machine 1935521.
/( )\ Shrewsbury, New Jersey http://linuxcounter.net
^^-^^ 11:50:01 up 18 days, 12:23, 3 users, load average: 5.97, 4.89, 4.82
7 years, 11 months
SELinux user label problem with Samba share files
by Jeff Boyce
Greetings -
A coworker ran into a (permission denied) problem recently trying to
save a file on our Samba server. So I first checked into the normal
user and group permissions for the user and the file, and everything
seemed fine there. So then I moved on to investigating whether it was
an SELinux issue, and subsequently I think I found more problems on our
Samba server than I wanted to see.
A short description of the issue that I see is that while the files on
my Samba share are labeled with the samba_share_t type, there is a
mixture of two different SELinux user labels. Some directories/files
are labeled with system_u and others are labeled with unconfined_u. The
particular file that the coworker was trying to save (and received a
permission denied result) had a system_u label. An example of the
mixture is shown below.
[root@sequoia CorporateDocs]# ls -lZ
drwxrws--T. eileenm mei_office system_u:object_r:samba_share_t:s0 Amendments
drwxrws--T. jeffb meiboard unconfined_u:object_r:samba_share_t:s0
Budget Materials
-rwxrw----. eileenm mei_office system_u:object_r:samba_share_t:s0
Ltr_Engagement_Mclanahan.pdf
drwxrws--T. jeffb meiboard unconfined_u:object_r:samba_share_t:s0 MEI
Stock
-rwxrw----. eileenm mei_office system_u:object_r:samba_share_t:s0
Original By-laws.pdf
Our setup in this small office includes a Samba file server that is
accessed by all staff through their Windows desktop/laptop systems. We
have a half a dozen main directories under our primary share with only
one of them restricted to a subset of the staff as diagrammed below.
The restricted subset is defined by standard user and group restrictions.
Ecosystem Share
Projects - all staff
Proposals - all staff
Reference - all staff
CorporateAdmin - restricted subset of staff
I suspect that the mixture of selinux user labels was a result of our
migration to this CentOS 6 server (a KVM guest if that matters) a couple
years ago from a pre-selinux RHEL 3 server. I thought I had all my
Samba selinux settings setup correctly when doing the migration, but I
guess not. I am actually surprised that we haven't run into the issue
earlier.
My goal now is to get all the selinux user labels uniformly correct and
solve the permission denied error that my coworker encountered. I am
hoping the first solves the second, and doesn't conflict with it.
Although I am not sure which label is correct for my situation, system_u
or unconfined_u. And if it is system_u, then why the permission denied
issue on that particular file. They don't have the same issue with
other files in other directories that have a system_u label.
I have read through the RHEL SE Linux User guide an am not sure where to
go from here. So I am looking for some guidance from the experts here.
I looked into the
/etc/selinux/targeted/contexts/files/file_contexts.local file and see
the following information. Maybe this is messed up also; or a
contributing factor to my issue.
# This file is auto-generated by libsemanage
# Do not edit directly.
/ecosystem(/.*)? system_u:object_r:samba_share_t:s0
/home/jeffb/messages system_u:object_r:user_home_t:s0
./CorporateDocs system_u:object_r:samba_share_t:s0
Any guidance appreciated. You may cc me directly as I only get the
daily digest of this list. Thanks.
Jeff
--
Jeff Boyce
Meridian Environmental
www.meridianenv.com
7 years, 11 months
