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
7 years
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
8 years, 1 month
Odd selinux complaints on new, fully updated CentOS 7
by mark
Just installed 7.2, and I'm seeing this - is this a bug in the policy?
**************************
SELinux is preventing systemd-readahe from add_name access on the
directory .readahead.new.
***** Plugin catchall_labels (83.8 confidence) suggests
*******************
If you want to allow systemd-readahe to have add_name access on the
.readahead.new directory
Then you need to change the label on .readahead.new
Do
# semanage fcontext -a -t FILE_TYPE '.readahead.new'
where FILE_TYPE is one of the following: device_t, init_var_run_t,
readahead_var_lib_t, readahead_var_run_t, root_t, var_run_t.
Then execute:
restorecon -v '.readahead.new'
***** Plugin catchall (17.1 confidence) suggests
**************************
If you believe that systemd-readahe should be allowed add_name access on
the .readahead.new directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep systemd-readahe /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Additional Information:
Source Context system_u:system_r:readahead_t:s0
Target Context system_u:object_r:mnt_t:s0
Target Objects .readahead.new [ dir ]
Source systemd-readahe
Source Path systemd-readahe
Port <Unknown>
Host <hostname>
Source RPM Packages
Target RPM Packages
Policy RPM selinux-policy-3.13.1-60.el7_2.3.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Permissive
Host Name <hostname>
Platform Linux <hostname> 3.10.0-327.10.1.el7.x86_64
#1 SMP Tue Feb 16 17:03:50 UTC 2016 x86_64
x86_64
Alert Count 4
First Seen 2016-02-29 10:06:27 EST
Last Seen 2016-02-29 16:50:22 EST
Local ID 0ba32e6a-e502-45be-a2dc-cda4c380a2bb
Raw Audit Messages
type=AVC msg=audit(1456782622.230:435): avc: denied { add_name } for
pid=410 comm="systemd-readahe" name=".readahead.new"
scontext=system_u:system_r:readahead_t:s0
tcontext=system_u:object_r:mnt_t:s0 tclass=dir
Hash: systemd-readahe,readahead_t,mnt_t,dir,add_name
*****************************************
mark
8 years, 1 month
udev-configure-printer AVC on chr_file 003
by Robert Nichols
In CentOS 6.7 with Windows 7 running in a QEMU/KVM virtual machine,
when I power-on a printer that the Windows VM uses via networking
I get the below AVC alert. Anyone have any idea what is going on?
I haven't noticed anything not working.
SELinux is preventing /lib/udev/udev-configure-printer from read access
on the chr_file 003.
***** Plugin catchall (100. confidence) suggests
***************************
If you believe that udev-configure-printer should be allowed read access
on the 003 chr_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep udev-configure- /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Additional Information:
Source Context
system_u:system_r:cupsd_config_t:s0-s0:c0.c1023
Target Context system_u:object_r:svirt_image_t:s0:c255,c554
Target Objects 003 [ chr_file ]
Source udev-configure-
Source Path /lib/udev/udev-configure-printer
Port <Unknown>
Host omega-3g.local
Source RPM Packages
system-config-printer-udev-1.1.16-25.el6.x86_64
Target RPM Packages
Policy RPM selinux-policy-3.7.19-279.el6_7.8.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name omega-3g.local
Platform Linux omega-3g.local 3.18.21-16.el6.x86_64
#1 SMP
Sat Sep 26 01:24:19 UTC 2015 x86_64 x86_64
Alert Count 1
First Seen Sat 13 Feb 2016 06:18:29 PM CST
Last Seen Sat 13 Feb 2016 06:18:29 PM CST
Local ID c3c9d30e-0835-4402-b342-acddd26e1686
Raw Audit Messages
type=AVC msg=audit(1455409109.607:29449): avc: denied { read } for
pid=32326 comm="udev-configure-" name="003" dev="devtmpfs" ino=2706
scontext=system_u:system_r:cupsd_config_t:s0-s0:c0.c1023
tcontext=system_u:object_r:svirt_image_t:s0:c255,c554 tclass=chr_file
permissive=0
type=SYSCALL msg=audit(1455409109.607:29449): arch=x86_64 syscall=open
success=no exit=EACCES a0=7ffe1bd16eb0 a1=0 a2=d a3=0 items=0 ppid=1
pid=32326 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=udev-configure-
exe=/lib/udev/udev-configure-printer
subj=system_u:system_r:cupsd_config_t:s0-s0:c0.c1023 key=(null)
Hash: udev-configure-,cupsd_config_t,svirt_image_t,chr_file,read
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
8 years, 1 month
In Fedora 23module name defined by policy_module is being ignored
by Miroslav Vadkerti
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi,
In Fedora 23 the policy_module declaration is ignored and the policy module name
is taken from the module filename. This can cause confusion for the users in
some cases (same policy module declared in different files).
# cat test_noaccess.te
policy_module(policy_tools_test, 1.0)
[snip]
# make -f /usr/share/selinux/devel/Makefile
Compiling mls test_noaccess module
/usr/bin/checkmodule: loading policy configuration from tmp/test_noaccess.tmp
/usr/bin/checkmodule: policy configuration loaded
/usr/bin/checkmodule: writing binary representation (version 17) to
tmp/test_noaccess.mod
Creating mls test_noaccess.pp policy package
rm tmp/test_noaccess.mod.fc tmp/test_noaccess.mod
# semodule -i test_noaccess.pp | grep noaccess
test_noaccess
If the policy_module is now being ignored, could the policy module
"compilation" print a warning about that? Or, maybe better, to generate the
module name according to the policy_module specification so we do not regress
in the behavior?
Thanks and best regards,
/M
- --
Miroslav Vadkerti :: Senior QE / RHCSS :: BaseOS QE - Security
IRC mvadkert at #qe #urt #brno #rpmdiff :: GnuPG ID 0x25881087 at pgp.mit.edu
Phone +420 532 294 129 :: Mobile +420 773 944 252
Red Hat s.r.o, Purkyňova 99/71, 612 45, Brno, Czech Republic
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJWzdP1AAoJEBliWhMliBCHrFcH/352QSpGLjqrKqYoUXkMAtzn
8eG+xn8wFjcSjjiGizD3vP0zJo79Qt13c9gZd9IvRbLqn/yCox0l38AA3qM1DA2Q
hIguhUynz8nOVhewoxA56ToZl2z5Kvm87Bkc9X9PiMhYO1QhYvikF0DPJhAnGGQw
m/xgZ/8Qm1KY3aMvxmgdqZXRiSfAO2aqPYIYLwZtGkNSntxhHQux2kLB7XSsYjhc
ZIQmhSLTIV859Rhb8QykUmAlVMwkOqQ8CRLBHNCHp+2mdYpmZu91Ioh4JsEBpWD3
O+u12ZEshxBjghfQspocjrwRI5Z2DMphLDS0PNQEq4zQkO0IgOge7FJvoLSMOps=
=QPVY
-----END PGP SIGNATURE-----
8 years, 1 month
Centos 7, /var/lib/ssh-x509-auth/
by mark
I assume that this is created by ssh when the user goes to ssh from their
system. So, why would I get
If you want to allow ksh93 to have create access on the kmeyer.pem file
Then you need to change the label on <username>.pem
Do
# semanage fcontext -a -t FILE_TYPE '<username>.pem'
where FILE_TYPE is one of the following: abrt_var_cache_t, auth_cache_t,
auth_home_t, cgroup_t, faillog_t, gitosis_var_lib_t, gkeyringd_tmp_t,
krb5_host_rcache_t, lastlog_t, mozilla_plugin_tmp_t,
mozilla_plugin_tmpfs_t, nfs_t, openshift_tmp_t, pam_var_run_t, ssh_home_t,
sshd_var_run_t, systemd_passwd_var_run_t, user_tmp_t, var_auth_t.
Then execute:
restorecon -v '<username>.pem'
ll -aZ /var/lib/ssh-x509-auth/
drwx------. adm root system_u:object_r:var_lib_t:s0 .
drwxr-xr-x. root root system_u:object_r:var_lib_t:s0 ..
-rw-------. adm adm system_u:object_r:var_lib_t:s0 <username>
-rw-------. adm adm system_u:object_r:var_lib_t:s0 <username>.pem
Is this a bug, a mislabeling, or...?
mark
8 years, 1 month
SELinux Userspace Release 20160107-rc1
by Petr Lautrbach
Cheers,
I've built and pushed SELinux Userspace Release 20160107-rc1 [1] into
Fedora Rawhide. It's already available via standard update paths.
Updated packages:
checkpolicy-2.5-0.1.rc1.fc24
libselinux-2.5-0.1.rc1.fc24
libsemanage-2.5-0.1.rc1.fc24
libsepol-2.5-0.1.rc1.fc24
policycoreutils-2.5-0.1.rc1.fc24
setools-3.3.8-10.fc24
secilc-2.5-0.1.rc1.fc24 is still missing due to the broken dependencies
for pandoc package.
If you want to try/use it on Fedora 23 you can update packages from my
COPR plautrba/selinux repository [1]. You would need to rebuild the
policy after the update as selinux-policy-targeted.fc23 doesn't ship
/var/lib/selinux/targeted/active/policy.kern file.
[1] https://github.com/SELinuxProject/selinux/wiki/Releases
[2] https://copr.fedorainfracloud.org/coprs/plautrba/selinux/
Thanks,
Petr
--
Petr Lautrbach
8 years, 1 month
