Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 7 Mar 2006 12:14:01 -0500
From:      Tom Rhodes <trhodes@FreeBSD.org>
To:        Hiroki Sato <hrs@FreeBSD.org>
Cc:        trustedbsd-discuss@FreeBSD.org
Subject:   Re: question about MAC policy modules on 6.0
Message-ID:  <20060307121401.3bb2bcec.trhodes@FreeBSD.org>
In-Reply-To: <20060308.015844.98687889.hrs@allbsd.org>
References:  <20060308.015844.98687889.hrs@allbsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 08 Mar 2006 01:58:44 +0900 (JST)
Hiroki Sato <hrs@FreeBSD.org> wrote:

> Hi,
> 
>  After testing some MAC policy modules on 6.0R, I have the following
>  questions about the implementation and the startup script:
> 
>  1) default value of security.mac.bsdextended.firstmatch_enabled
> 
>   mac_bsdextended(4) says the following:
> 
>   |  security.mac.bsdextended.firstmatch_enabled
>   |           Toggle between the old all rules match functionality and the new
>   |           first rule matches functionality.  This is enabled by default.
> 
>   however, the corresponding implementation is as follows:
> 
>   |static int
>   |mac_bsdextended_firstmatch_enabled;
>   |SYSCTL_INT(_security_mac_bsdextended, OID_AUTO, firstmatch_enabled,
>   |      CTLFLAG_RW, &mac_bsdextended_firstmatch_enabled, 1,
>   |      "Disable/enable match first rule functionality");
> 
>   Which is intended?  If the manual page is correct, the attached patch (the
>   first one) is needed, I think.
> 
>  2) rc.bsdextended
> 
>   Currently /etc/rc.bsdextended is used as the default rules when
>   ugidfw_enable=yes in /etc/rc.conf, but this configuration is
>   not so generic and problematic in some cases.  For example,
>   it includes rules for applications not in the base system, and
>   especially "awk -F: '($3 >= 1001) && ($3 != 65534) { print $1 }'
>   /etc/passwd" line does not work on systems which have a lot of
>   users because the current ugidfw supports 256 slots only.
>   Also, I am wondering why the "${CMD} add subject uid 0 object not
>   uid 0 mode arxws;" is included.  Does the mac_bsdextended module
>   support rules for UID 0?
> 
>   I guess that this is still work-in-progress, but since it has
>   been merged into the RELENG_6 branch, I think we have to polish
>   the default script.  So, I am just wondering:
> 
>    a) What is the master plan of rc.d scripts for MAC policy
>       modules?  I think it is better to have /etc/rc.d/mac_bsdextended,
>       and knobs of $mac_bsdextended and $mac_bsdextended_script in rc.conf
>       for more consistency, but we have /etc/rc.d/ugidfw, $ugidfw_enable,
>       and $bsdextended_script.  If there are some policies on
>       that already discussed, I am interested in them.
>    b) Is the current content of /etc/rc.bsdextended reasonable
>       as an example?  I think it is too aggressive and most of the
>       rules should be commented out by default.
>    c) Does mac_bsdextended really support rules for UID 0?  The current
>       /etc/rc.bsdextended script includes such rules, but the implementation
>       does not support them as far as I know.  Are they going to be supported
>       in the near future (or just a mistake)?

The startup was a quickie thing I added because, well, we
were using it where I worked at the time.  In all honesty,
that script needs a clean up, and I have a test machine
set up at work for doing this.  Unfortunately that script
has rotted, 256 slots does not help, etc etc.  If you
have any tests for it, I'll gladly play at work this
week/weekend.


> 
>  3) src/share/security/* not installed
> 
>   setfsmac(8) mentions /usr/share/security/lomac-policy.contexts in
>   the FILES section, but the actual file is not installed.
>   That file is src/share/security/lomac-policy.contexts in the source
>   tree.  Are there any reason not to hook it up to the build?

I brought this up with Robert over a year and I think the
discussion just died.

> 
>  4) mount_ufs(8) multilabel option
> 
>   mount_ufs(8) has multilabel option for the MAC label, but it
>   seems broken ("tunefs -l enable" works, though).  I am not sure
>   the attached patch (the second one) is correct, but it should
>   fix this.
> 
>  I am still not familiar with development of Trusted BSD feature,
>  and maybe the above problems are solved already somewhere else or
>  just I get wrong ideas, but if anyone knows the details or if
>  I am missing something, please let me know.  Thanks.

I've also noticed some other issues.  A freshly installed 6.0
does not allow me to set biba labels, even with multilabel
set.  Still looking into that, it could just be a simple
configuration error; however, the system has had no additional
configuration other than 'options MAC' added and installed.

-- 
Tom Rhodes



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060307121401.3bb2bcec.trhodes>