selinux February 2016

selinux@lists.fedoraproject.org

6 participants
7 discussions

Re: RHEL 7 consoletype_exec interface issue
by Douglas Brown 27 Mar '17

27 Mar '17

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

3 2

Puzzle involving sudo_role_template, shell script context, file type in /tmp
by Lou Hafer 11 Mar '16

11 Mar '16

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

2 2

Odd selinux complaints on new, fully updated CentOS 7
by mark 04 Mar '16

04 Mar '16

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

2 1

udev-configure-printer AVC on chr_file 003
by Robert Nichols 25 Feb '16

25 Feb '16

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.

2 6

In Fedora 23module name defined by policy_module is being ignored
by Miroslav Vadkerti 25 Feb '16

25 Feb '16

-----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-----

2 3

Centos 7, /var/lib/ssh-x509-auth/
by mark 24 Feb '16

24 Feb '16

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

2 2

SELinux Userspace Release 20160107-rc1
by Petr Lautrbach 22 Feb '16

22 Feb '16

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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux February 2016