[DSE-Dev] Fixing up SELinux reference policy for Debian

[Manoj Srivastava]

On Wed, 16 May 2007 22:54:00 +1000, Russell Coker <russell at coker.com.au> said: 

> I have attached a patch that I'm using in my work on getting a strict
> unstable system to work.

        Applied the changes, and uploaded a new refpolicy package.

> I believe that cron should be allowed to set limits, although this
> could possibly be done in a boolean.

        I have not yet made this change.  I have discovered additional
 issues with cron; 
,----
| #============= 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="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;
| #============= 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 };
`----

        I want to look into these a bit more before making the changes
 in refpolicy.

> fsadm_t asks for security_t because it's linked against libblkid.so.1
> which is linked against libdevmapper.so.1.02.1 which is linked against
> libselinux.so.1.  The load phase of libselinux.so.1 will access things
> under /selinux.  I posted to the SE Linux list about this issue last
> night but haven't got any replies yet.  I suggest no policy changes in
> this regard until we get things sorted out correctly (don't want to
> hide problems).

> The mount_t security_t issue is the same as for fsadm_t.

> I think it's appropriate for semanage_t to access security_t even
> though it might not need it at the moment (it's an area that's
> evolving and semanage_t can break things anyway).

> Above is the code from unix_chkpwd.c that uses libselinux and
> therefore wants to access security_t.  I think it would be a bad idea
> to prevent such access.

        I have not made these changes yet, but it seems like it should
 do no harm to permit these.

> The mountnfs is one I think I haven't solved yet.

> I don't know why unix_chkpwd is looking under /var/run, does it fail
> to work when that access is prevented?

        Not in the cases I have observed.

        However, when cretaing the refpolicy package itself, I can
 across this little denial while linking:
,----
| #============= user_t ==============
| # src="user_t" tgt="shlib_t" class="file", perms="ioctl"
| # comm="ld" exe="" path=""
| allow user_t shlib_t:file ioctl;
`----

        Shouldn't that be allowed?

        manoj
-- 
* JHM wonders what Joey did to earn "I'd just like to say, for the
  record, that Joey rules." -- Seen on #Debian
Manoj Srivastava <srivasta at debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C