On Wed, 3 May 2006, Borja Marcos wrote:
> I've been looking at the different MAC modules available and how they
cold
> help to implement a less insecure than usual shared hosting web server.
I think this sounds interesting :-).
I think the approach you've described sounds like the right sort of approach
-- a hybrid model that allows the web server to tell the kernel when its
switching to a particular user domain, taking advantage of existing user
credential elements, etc. I guess what I'd start out by doing is
identifying
what it is you want to protect against, and specifically, write a couple of
short stories (a few sentences) describing specific sequences of events you
want to protect against with the policy. It sounds like, in particular,
you're looking for an outcome that could be expressed using mac_bsdextended,
but perhaps not efficiently due to the number of rules it would take to
implement.
Part of what you describe sounds like you're thinking of assigning levels to
objects and subjects. I guess I would caution that this adds significant
complexity to a policy, so you might think about whether it's necessary to
protect against the sorts of attacks you're worried about. If you need it,
then it can be done, but if you can avoid it, it may significantly reduce the
complexity. BTW, you might want to take a look at some of the recent changes
made by David Malone to mac_bsdextended, which allow you to add security rules
involving file systems, so you can say things like "users in group X
can't
write to /usr" and the like. It might be you could add a bit more
flexibility
to mac_bsdextended to get some of what you're looking for.
Robert N M Watson
>
> I've not been able to come up with a suitable configuration, looking at
> mac_bsdextended, mac_biba and mac_mls, but I think that a MAC module with
the
> following policies could be very useful for such an environment. Have I
> missed anything? Has something similar been done?
>
> The module would (roughly) work as follows:
>
> Defining security levels in a similar way to mac_mls or mac_biba,
>
> we define a range of uids as sysctl variables to be used as
"compartiments".
> For example,
>
> mac.mac_uids.lowuid
> mac.mac_uids.highid
>
> And it would be implemented so that:
>
> Below a given security level, (mac.mac_uids.enforce_below)
>
> - Any operation of a subject with uid x (between lowuid and highuid) on an
> object with uid y (between lowuid and highuid) would fail.
>
> - A subject with a given security level could not modify an object with a
> higher security level.
>
> This, combined with a chroot tree would (I think) be much better than the
> typical solutions available. The webserver process would be launched as a
> low-security subject, and it is assumed that it would make a setuid()
before
> launching a CGI process. And perhaps it wouldn't be so hard to modify
an
> existing webserver so that it changed the uid when serving a page
associated
> with a virtual server, adding a uid parameter to virtual servers.
>
> What do you think? Ideas? (This is only a quick and dirty idea)
>
>
>
>
>
>
>
> Borja.
>
> _______________________________________________
> freebsd-security@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to
"freebsd-security-unsubscribe@freebsd.org"
>