Fw: PERFORCE change 18676 for review

[Robert Watson]

On Wed, 16 Oct 2002, Adam Migus wrote:

> Please note, Robert and I have two separate sets of changes pending
> integration into the main MAC tree.  Roberts are kernel string handling
> and associated libc changes.  Mine are framework/policy and
> framework/userland API changes.  Both of these changes will likely
> affect how this would be implemented.  Thus I'd hold off until you see
> them in the tree.  ETA on Roberts patch is 1-2 days, ETA on mine is 2-3
> days. 

I just committed the new user API changes to the TrustedBSD MAC branch. 
Perforce commit message attached below.  Once this has been reviewed some,
I'll push it over to the main tree before 5.0-RELEASE.  I'll try to get a
review done of your sysctl framework changes in your branch done tomorrow
and we can merge them to the main TrustedBSD MAC branch sometime in the
next day or two.  I'm also aiming to get the new VFS code into the MAC
tree over the weekend, which should improve VFS performance as well as fix
issues with shared vnode locks. 

Date: Thu, 17 Oct 2002 20:14:12 -0700 (PDT)
From: Robert Watson <rwatson at FreeBSD.org>
To: Perforce Change Reviews <perforce at freebsd.org>
Subject: PERFORCE change 19525 for review

http://perforce.freebsd.org/chv.cgi?CH=19525

Change 19525 by rwatson at rwatson_tislabs on 2002/10/17 20:13:35

        Hopefully approaching the final revision on the MAC user
        API for FreeBSD 5.0.  This continues to take much the same
        approach to prior label processing, but differs in the
        following ways:
        
        (1) Previously, mac.c in libc broke down labels into their
            component elements, and passed them to the kernel via
            a variable-length array of 'struct mac_element'.  When
            retrieving labels, the same approach was taken.  In the
            new approach, this split is performed by the kernel
            code, and only a single string is read in.  This
            dramatically simplifies the copyin/out and validation
            operations, and removes the copyin's/copyout's from the
            individual modules (they now just deal with in-kernel
            strings).  Modules receive 'element_name' and
            'element_data', and may claim entries as before -- if
            claimed, a destructive parsing of the string may be
            performed in order to extract useful data.
        
        (2) Permit label names in /etc/mac.conf to be prefixed with
            a '?' indicating that failure to retrieve the label
            element should not be considered a fatal error, allowing
            entries to appear in mac.conf even if the kernel module
            supporting the element name is not present.  Populate
            the default mac.conf with entries for each of our
            labeled policies, which means mac.conf doesn't have to
            be modified if any of them is loaded.  Third party
            policies will still require configuration.
        
        (3) Temporarily remove all support for userland modules, since
            all of the existing functionality is now encapsulated
            in the kernel policy modules.  We may wish to reintroduce
            this module support for the purposes of permitting userland
            mapping of label element data--however, almost all the
            current code would be inappropriate for that, so we'll
            just remove it, making mac.c almost empty.
        
        There is room for further improvement, including relating to
        the 'claimed' model, errno values, etc.
        
        I've tested all policies except sebsd, which I don't have a
        run-time configuration for, but it appears to build properly
        and 'looks right'.  There are probably bits.  I'd also
        appreciate a detailed review of the string parsing code for
        labels, as if there are any serious problems, the results
        could be relatively catastrophic.
        
        I'll let this settle in the MAC tree for a few days, and if
        all goes well, migrate the changes to the main tree over
        the weekend, giving re@ approval.




To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message