[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Fixing up SELinux reference policy for Debian

On Sat, 12 May 2007 18:56:02 +0200, Erich Schubert <erich@debian.org>

>> After that, I need to start branching out, and adding, say, apache2
>> servers to my UML, and checking validity of strict policy.

> We'd also need people to work on e.g. an exim and a tomcat policy.

        I don't use exim, or tomcat, so this is likely to take me
 longer.  The version I uploaded last night now fixes all the problems I
 saw last time, and includes the changes that Russell posted (updated
 localStrict.te included below).  I can compile my packages, and run
    apt-get update && aptitude install localepurge 
 without problems.

        However, I noticed that installing packages can still cause AVC
 denials (like, flashplayer non-free packages download files from the
 internet, installing auditd caused a whole flurry of denials). I think
 we need a whole new auditd policy, in fact.  I'll follow up on the
 selinux-devel@lists.alioth.debian.org list in a separate email on
 that -- I have a log of the console messages from an upgrade session.

        I think a number of these things that happen in post install
 scripts might require Debian specific policy, since I suspect Debian
 does far more in the postinst phase than does Fedora.

>> Given the magnitude of these changes, I am planning on trying to do a
>> backport of SELinux packages for Etch, at least, for the current
>> release, before the kernel requirements diverge too much.

> I'm with you on that. We really should provide backports to offer
> powerful SELinux support for etch. There are just too many small
> issues with etch that break it one place or another.  (Such as liblzo
> breaking openvpn; http://bugs.debian.org/336138 ) We should try to get
> SELinux *strict* on etch into shape so people can use it on firewalls
> (including openvpn and IPSec), common mail and web server setups with
> little effort (well, lets say 'without cgi and complex PHP things'
> because that is an endless field then).  Maybe propose them for a
> maintainance release even.

        I am now waiting for things to move into testing before doing a
 backport, as suggested by the guidelines.  Thanks to the admins, my key
 is in the backports keyring, so I am all set there.


module localSrict 1.0;

require {
	type var_run_t;
	type fsadm_log_t;
	type apt_var_lib_t;
	type mount_t;
	type system_crond_t;
	type fsadm_t;
	type initrc_t;
	type user_t;
	type system_chkpwd_t;
	type logrotate_t;
	type crond_t;
	type var_t;
	type shlib_t;
	type security_t;
	class file { write rename getattr setattr read create ioctl };
	class fd use;
	class fifo_file { write read ioctl };
	class dir { write search remove_name add_name };
	class filesystem getattr;

#============= fsadm_t ==============
# src="fsadm_t" tgt="security_t" class="filesystem", perms="getattr"
# comm="fsck.ext3" exe="" path=""
allow fsadm_t security_t:filesystem getattr;

#============= initrc_t ==============
# src="initrc_t" tgt="crond_t" class="fifo_file", perms="{ read ioctl }"
# comm="sysklogd" exe="" path=""
allow initrc_t crond_t:fifo_file { read ioctl };
# src="initrc_t" tgt="fsadm_log_t" class="file", perms="write"
# comm="logsave" exe="" path=""
allow initrc_t fsadm_log_t:file write;
# src="initrc_t" tgt="system_crond_t" class="fd", perms="use"
# comm="sysklogd" exe="" path=""
allow initrc_t system_crond_t:fd use;
# src="initrc_t" tgt="system_crond_t" class="fifo_file", perms="write"
# comm="sysklogd" exe="" path=""
allow initrc_t system_crond_t:fifo_file write;

#============= logrotate_t ==============
# src="logrotate_t" tgt="var_t" class="dir", perms="{ write remove_name add_name }"
# comm="mv" exe="" path=""
allow logrotate_t var_t:dir { write remove_name add_name };
# src="logrotate_t" tgt="var_t" class="file", perms="{ rename getattr }"
# comm="savelog" exe="" path=""
allow logrotate_t var_t:file { rename getattr };

#============= mount_t ==============
# src="mount_t" tgt="security_t" class="filesystem", perms="getattr"
# comm="mount" exe="" path=""
allow mount_t security_t:filesystem getattr;

#============= system_chkpwd_t ==============
# src="system_chkpwd_t" tgt="security_t" class="filesystem", perms="getattr"
# comm="unix_chkpwd" exe="" path=""
allow system_chkpwd_t security_t:filesystem getattr;
# src="system_chkpwd_t" tgt="var_run_t" class="dir", perms="search"
# comm="unix_chkpwd" exe="" path=""
allow system_chkpwd_t var_run_t:dir search;

#============= system_crond_t ==============
# src="system_crond_t" tgt="apt_var_lib_t" class="file", perms="read"
# comm="cp" exe="" path=""
allow system_crond_t apt_var_lib_t:file read;
# src="system_crond_t" tgt="var_t" class="dir", perms="{ write add_name }"
# comm="cp" exe="" path=""
allow system_crond_t var_t:dir { write add_name };
# src="system_crond_t" tgt="var_t" class="file", perms="{ write create setattr }"
# comm="cp" exe="" path=""
allow system_crond_t var_t:file { write create setattr };

#============= user_t ==============
# src="user_t" tgt="shlib_t" class="file", perms="ioctl"
# comm="ld" exe="" path=""
allow user_t shlib_t:file ioctl;

There are more things in heaven and earth than any place else.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Reply to: