| Main Archive Page > Month Archives > selinux archives |
Re: MLS directory write constraints
From: Klaus Weidner <klaus_at_nospam>Date: Thu Aug 23 2007 - 23:05:19 GMT
To: "Christopher J. PeBenito" <cpebenito@tresys.com>
On Tue, Aug 21, 2007 at 09:10:23AM -0400, Christopher J. PeBenito wrote:
> On Mon, 2007-08-20 at 15:52 -0500, Klaus Weidner wrote:
> > Ranged directories are an information leak in an MLS system, the current
> > restrictions are intentionally set the way they are to prevent them.
> >
> > For the CC evaluation of LSPP compliance, we needed to draw a line
> > between explicit data flows (which need to be enforced by the OS), and
> > covert channels (which are beyond the scope of the evaluation).
> >
> > The method we used to decide this was to check if an interface allows
> > creation of arbitrary textual/binary data that can be read at another
> > level - if that's the case, the OS needs to enforce the strict LSPP MLS
> > constraints and prevent write down. Unfortunately directory write
> > operations to ranged directories would break this constraint since the
> > filenames can be chosen arbitrarily and read at lower levels, and this
> > must not be allowed for untrusted subjects.
>
> Does RHEL5 LSPP have a polyinstantiated /var/run? If not, then every
> daemon that doesn't run with a system low level will need this at a
> minimum, thus partially negating what you are trying to do.
By default /var/run doesn't get polyinstantiated in the LSPP config, and I'm not sure if that would have the desired effect. The polyinst namespace gets chosen at login time based on the interactive user's properties, so it would not do the right thing for daemons.
It's fine from the CC/LSPP perspective if noninteractive system daemons have a ranged-directory override attribute for their type, as long as the interactive users are properly limited. It's still a lot better than globally permitting everyone to write to ranged directories.
I don't think that the ranged directory write permission for those few daemons that don't run at SystemLow is a serious security concern in practice. A main intent of LSPP is to protect against hostile code run by a user that downgrades information, and TE provides protection against them abusing system services for that purpose.
In the long term, I think it would be preferable to use different level-specific directories instead of /var/run/ for other levels, but I'm not sure if namespace polyinstantiation is the best solution for this. It could also be configured specifically at run- or compile-time for apps that run at SystemHigh.
> I see that the constraints are different in the 2.4.6-67 LSPP policy.
> Is this the final one? I want to make sure that the LSPP policy changes
> have been integrated upstream.
selinux-policy-2.4.6-67.el5 is the evaluated version, that's the one that is known to match LSPP requirements. The version in the older thread that I linked to wasn't final yet, we had made some minor modifications last year to get to the final version. Please use the selinux-policy-2.4.6-67.el5 constraints for upstream if possible.
-Klaus -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.