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

[Russell Coker]

> >         I am attaching the local.te file below for comment; some of
> >  this should probably go into the refpolicy package, and, eventually,
> >  upstream.
>
>         Would be nice to actually append the file.

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

Some comments on your patch:

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

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).

I fixed the /lib/init/rw issue.

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

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).

        /*
         * Determine the current user's name.
         * On a SELinux enabled system, policy will prevent third
         * parties from using unix_chkpwd as a password guesser.
         * Leaving the existing check prevents su from working, since
         * the current uid is the user's and the password is for root.
         */
        if (SELINUX_ENABLED) {
            user = argv[1];
        } else {
            user = getuidname(getuid());
            if (strcmp(user, argv[1])) {
                return PAM_AUTH_ERR;
            }
        }

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 don't know why unix_chkpwd is looking under /var/run, does it fail to work 
when that access is prevented?

-- 
russell at coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff
Type: text/x-diff
Size: 7545 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/selinux-devel/attachments/20070516/65b642a9/attachment.diff