Date: Thu, 4 May 2006 17:28:24 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Borja Marcos <BORJAMAR@SARENET.ES> Cc: freebsd-security@freebsd.org Subject: Re: MAC policies and shared hosting Message-ID: <20060504172309.D17611@fledge.watson.org> In-Reply-To: <CB6E482F-221F-4D31-8814-BF4A23D3E19E@SARENET.ES> References: <CB6E482F-221F-4D31-8814-BF4A23D3E19E@SARENET.ES>
next in thread | previous in thread | raw e-mail | index | archive | help
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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060504172309.D17611>