ifdef policy blocks for different releases?
by Douglas Brown
Hi,
Is there a way to write one policy for both RHEL 6 and RHEL 7?
This sort of thing, but release based rather than distro:
ifdef(`distro_redhat’,`
optional_policy(`
systemd_passwd_agent_exec($1)
systemd_read_fifo_file_passwd_run($1)
‘)
‘)
If not, could someone please point me in the direction of some best practices?
Thanks,
Doug
8 years, 5 months
[docker-selinux] Move docker interfaces from docker-selinux to selinux-policy dist-git repo.
by Lukas Vrabec
Hi!
I would like to introduce the latestchanges inthe docker selinux policy.
In Fedora Rawhide and 23, selinux-policyfor dockeris shipped separately
as adocker sub-package. This is quite a problem when we want to add
ruleslike: /"docker_stream_connect(abrt_t)" /to distro policy/. /The
abrt policy is shipped in theselinux-policy package but
thedocker_stream_connectinterfaceis shipped in thedocker-selinux
package. So we cannot add this rule totheabrt policy because of the
docker interface notbeingdefined during the selinux-policy build.
The solution is that we movethe docker selinux interfaces
totheselinux-policy package and the rest ofthefiles isshipped in
thedocker-selinux package.
The disadvantage of this solution is that everytime we build a new
selinux-policy package we need to download the latestdocker selinux-policy.
Thesechanges have beenpushed to Fedora Rawhide, so please,if you find
any problem,let me know!
Thank you!
--
Lukas Vrabec
SELinux Solutions
Red Hat, Inc.
8 years, 6 months
Docker.if potential conflict
by William Brown
Hi,
I was reading this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1262812
And I noticed that even once updated (and making sure that selinux
-policy-devel doesn't provide docker.if) that I still get on a build:
make -f /usr/share/selinux/devel/Makefile
/usr/share/selinux/devel/include/contrib/apache.if:277: Error:
duplicate definition of apache_exec(). Original definition on 131.
/usr/share/selinux/devel/include/kernel/kernel.if:3879: Error:
duplicate definition of kernel_unlabeled_domtrans(). Original
definition on 485.
/usr/share/selinux/devel/include/kernel/kernel.if:3900: Error:
duplicate definition of kernel_unlabeled_entry_type(). Original
definition on 478.
/usr/share/selinux/devel/include/kernel/files.if:7840: Error: duplicate
definition of files_write_all_pid_sockets(). Original definition on
494.
/usr/share/selinux/devel/include/kernel/filesystem.if:4537: Error:
duplicate definition of fs_dontaudit_remount_tmpfs(). Original
definition on 464.
/usr/share/selinux/devel/include/kernel/devices.if:221: Error:
duplicate definition of dev_dontaudit_list_all_dev_nodes(). Original
definition on 471.
/usr/share/selinux/devel/include/kernel/devices.if:4499: Error:
duplicate definition of dev_dontaudit_mounton_sysfs(). Original
definition on 501.
It looks like selinux-docker is still defining a bunch of interfaces
that it shouldn't. Is this the correct behaviour?
--
William <william(a)blackhats.net.au>
8 years, 6 months
SElinux newbie question
by David Li
Hi,
I am using CentOS 7.1 and just built the following new Selinux policy
RPMs. I wonder which one I should use in install. Or do I need to
install all of them?
My purpose is to test a simple policy that I wrote.
[admin@localhost noarch]$ ll
total 8996
-rw-rw-r--. 1 admin admin 361920 Oct 14 11:47
selinux-policy-3.13.1-23.el7.centos.noarch.rpm
-rw-rw-r--. 1 admin admin 3467872 Oct 14 11:47
selinux-policy-devel-3.13.1-23.el7.centos.noarch.rpm
-rw-rw-r--. 1 admin admin 917644 Oct 14 11:47
selinux-policy-doc-3.13.1-23.el7.centos.noarch.rpm
-rw-rw-r--. 1 admin admin 365812 Oct 14 11:47
selinux-policy-sandbox-3.13.1-23.el7.centos.noarch.rpm
-rw-rw-r--. 1 admin admin 4084412 Oct 14 11:47
selinux-policy-targeted-3.13.1-23.el7.centos.noarch.rpm
Thanks.
8 years, 6 months
Re: [CentOS] CentOS-6 SSHD chroot SELinux problem
by mark
James,
I don't have an answer, but you'll note that I replied to both the
CentOS list, and the more appropriate selinux list. Folks like Dan
Walsh are responders there.
mark
James B. Byrne wrote:
> I run a sshd host solely to allow employees to tunnel secure
> connections to our internal hosts. Some of which do not support
> encrypted protocols. These connections are chroot'ed via the
> following in /etc/ssh/sshd_config
>
> Match Group !wheel,!xxxxxx,yyyyy
> AllowTcpForwarding yes
> ChrootDirectory /home/yyyyy
> X11Forwarding yes
>
> Where external users belong to group yyyyy (primary).
>
> We have a problem with SELinux in that chrooted users cannot tunnel
> https requests unless SELinux is set to permissive (or turned off
> altogether). This problem does not evidence itself unless the account
> is chrooted.
>
> The output from audit2allow is this:
>
> sudo audit2allow -l -a
>
>
> #============= chroot_user_t ==============
> allow chroot_user_t cyphesis_port_t:tcp_socket name_connect;
> allow chroot_user_t user_home_t:chr_file open;
>
> #============= syslogd_t ==============
> #!!!! The source type 'syslogd_t' can write to a 'dir' of the
> following types:
> # var_log_t, var_run_t, syslogd_tmp_t, syslogd_var_lib_t,
> syslogd_var_run_t, innd_log_t, device_t, tmp_t, logfile,
> cluster_var_lib_t, cluster_var_run_t, root_t, krb5_host_rcache_t,
> cluster_conf_t, tmp_t
>
> allow syslogd_t user_home_t:dir write;
>
>
> My questions are:
>
> Do SE booleans settings exist that permit chrooted ssh access to
> forward https and log the activity? If so then what are they?
>
> If not, then have I made a configuration error in sshd_config? What
> is it?
>
> If not, then is this a defect in the SELinux policy?
>
> If not, then What are the implications of creating a custom policy to
> handle this using the output given above?
>
>
>
> --
> *** e-Mail is NOT a SECURE channel ***
> Do NOT transmit sensitive data via e-Mail
> James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
> Harte & Lyne Limited http://www.harte-lyne.ca
> 9 Brockley Drive vox: +1 905 561 1241
> Hamilton, Ontario fax: +1 905 561 0757
> Canada L8E 3C3
>
> _______________________________________________
> CentOS mailing list
> CentOS(a)centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
8 years, 6 months
