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

[Manoj Srivastava]

Hi,

        I have just uploaded a version of refpolicy that has a number of
 Debian specific SELinux policy changes. I can now do and aptitude
 update, and aptitude upgrade while running strict policy in enforcing
 mode in my UML machine.  The createfs.sh script now incorporates all
 the recommended changes on http://wiki.debian.org/SELinux/Setup, so it
 is relatively easy to create such a UML.
  http://www.golden-gryphon.com/software/security/selinux-uml.xhtml

        I also have a patch for sysvinit's /etc/network/if-up.d/mountnfs 
 to provide the context when creating /var/run/network/mountnft; if and
 only if we are running selinux.  I'll send in a wishlist bug report
 soon.

        My local policy file has been reduced to a single allow rule,
 and a bout half a dozen  dontaudit rules; and is now shipped with the
 strict policy package as an example.

        The single allow rule that I still need is due to Bug#390067, I
 have not yet had a chance to create a helper script that would do the
 logging, and which can be put into a different security domain.

        However, a more basic problem exists: as an ordinary user, I
 can't run dpkg-checkbuilddeps, or do anything that needs looking at
 /var/lib/dpkg -- since plain old users can't look into /var.

        I think we need to create debian specific policy changes to
 allow searching /var, /var/lib. and /var/lib/dpkg.  We also read file
 permissions on files in /var/lib/dpkg; and these need to be added to a
 generic user.

        Any objections? (I don't think I want to create a whole
 different class of user for this capability).  This would be the
 minimal requirements to start building my Debian packages in enforcing
 mode again.

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

        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.


        manoj
-- 
No use getting too involved in life -- you're only here for a limited
time.
Manoj Srivastava <srivasta at debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C