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
Adding confinement to an EPEL package
by James Hogarth
Hi all,
A while back my pull request to contribute a policy for sslh in Fedora was
accepted and indeed all users have been protected by having the daemon
confined if they use it since Fedora 23.
RHEL does not have the policy included so EPEL users aren't subject to the
same benefits of selinux of this network service.
I'd like to rectify this if possible (I'm going to ignore F22 given how
soon the EOL on it is and the change in behaviour that would result on
users).
The draft packaging guidelines for a policy in Fedora[1][2] are rather
archaic at this point but I figure I can base the changes to the spec on
this to an extent.
I have a few of questions/concerns though:
1) What is the consequence of someone having selinux disabled (common in
EL5 systems and to an extent EL6) with the semodule to install the .pp in
%post ? Will this prevent the package from being installed and if I
condition it based on getenforce output to avoid doing so on disabled
system if the admin then enables selinux will the module still be installed?
2) Is it better practice to have a separate -selinux package in the spec or
just do it in the one package? If a separate package what would be the best
way to ensure upgrading users get the policy? I see suggestions of a -core
package ... perhaps turn the main foo package into a dummy that requires
both -core and -selinux?
3) If the selinux maintainers in RHEL import the sslh policy from fedora
contrib at some point what affect would this have on my users? Would I need
to issue a new update without the .pp and uninstalling the module to allow
them to upgrade their selinux policy?
Cheers,
James
[1] https://fedoraproject.org/wiki/SELinux_Policy_Modules_Packaging_Draft
[2] https://fedoraproject.org/wiki/PackagingDrafts/SELinux
8 years
selinux query
by Naina Emmanuel
plz guide that how can we check/see that which selinux things we can use
for which system (.src.rpm)
coz i am having problem even installing some new .src.rpm pakg.
plzz guide me thanks
*Engr. Naina Emmanuel*
*Linux Essential Certified (LEPDC)*
*Cisco Certified Network Associate (CCNA)*
*Computer Engineering Department, UET Taxila*
*Information Security, CS Department, CIIT Islamabad*
8 years
selinux query
by Naina Emmanuel
Respected!
i am having issues in compiling and installing my modules with the error
#make -f /usr/share/selinux/devel/Makefile mysql.pp
/usr/share/selinux/devel/include/contrib/apache.if:277: Error: duplicate
definition of apache_exec(). Original definition on 131.
Compiling targeted mysql module
mysql.te:80: Warning: corenet_non_ipsec_sendrecv(mysqld_t) has been
deprecated, use corenet_all_recvfrom_unlabeled() instead.
/usr/bin/checkmodule: loading policy configuration from tmp/mysql.tmp
/usr/bin/checkmodule: policy configuration loaded
/usr/bin/checkmodule: writing binary representation (version 17) to
tmp/mysql.mod
Creating targeted mysql.pp policy package
rm tmp/mysql.mod.fc tmp/mysql.mod
[root@naina mysql]# semodule -i mysql.pp
libsepol.print_missing_requirements: os-mysql's global requirements were
not met: type/attribute mysqld_safe_exec_t (No such file or directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file or
directory).
semodule: Failed!
*Engr. Naina Emmanuel*
*Linux Essential Certified (LEPDC)*
*Cisco Certified Network Associate (CCNA)*
*Computer Engineering Department, UET Taxila*
*Information Security, CS Department, CIIT Islamabad*
8 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
Linux sandbox and the -i option
by Bill
Is anyone else having issues with the
% sandbox -i [path]
not working? What happens is the context is incorrectly done.
% rpm -q -f /usr/bin/sandbox shows I am using
policycoreutils-python-utils-2.4-20.fc23.x86_64
%ls -Zd /tmp/.sandbox_home_[whatever]
gives
unconfined_u:object_r:sandbox_file_t:s0:cxx,cyyy .
BUT
%ls -Z [path] is
gives
unconfined_u:object_r:mozilla_home_t:s0 [path]
This causes all sorts of read/write issues.
I guess I can write a script to do the
chcon, but that is a bit painful and you have to hunt
for the correct sandbox directory (not optimal at all).
Any suggestions?
Bill Chimiak
LTS
8 years, 1 month
Re: Confined Users and Cron
by Douglas Brown
Hi list,
We have a client who wants a service account’s crontab to run a ruby script in /var/www; this isn’t permitted by default and I have no idea what this script does but from past experience suspect it will generate an array of misleading AVCs if I go down the route of allowing crontab_t to read httpdcontent attribute (ie. httpd_sys_rw_content_t, etc.) files and directories. Could someone please explain the rationale behind the policy design for user crontab confinement and how I should handle this situation?
Thanks,
Doug
8 years, 1 month
sandbox -i is not working
by Bill
Is anyone else having issues with the
% sandbox -i [path]
not working? What happens is the context is incorrectly done.
%ls -Zd /tmp/.sandbox_home_[whatever]
gives
unconfined_u:object_r:sandbox_file_t:s0:cxx,cyyy .
BUT
%ls -Z [path] is
gives
unconfined_u:object_r:mozilla_home_t:s0 [path]
This causes all sorts of read/write issues.
I guess I can write a script to do the
chcon, but that is a bit painful and you have to hunt
for the correct sandbox directory (not optimal at all).
Any suggestions?
--
William Chimiak
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
