MAC policies and shared hosting
Borja Marcos
BORJAMAR at SARENET.ES
Wed May 10 14:57:41 UTC 2006
On 4 May 2006, at 18:28, Robert Watson wrote:
>
> 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 :-).
Well, after reading the documentation and some source code, I think
that a relatively simple approach is possible. In fact, I'm thinking
about writing an article describing the setup.
Each hosted website will have one or two users:
ftpwebhost: FTP update of the webpages ("webhost" being the customer
name)
cgiwebhost: CGI/PHP for the webite.
In this way, customers can restrict possible modifications done to
their web pages by an abused CGI. I guess most customers will want
only one user, but at least we can offer them the choice. Both users
would share a group, so that clueful users can grant permissions to
the cgiwebhost user. I was thinking about mls and compartments, but
it cannot be done without some cooperation from Apache, and ugidfw/
mac_bsdextended will be more than enough. BTW, why there are only 256
compartments?
The ftpwebhost and cgiwebhost user ids' will be members of an
interval, imagine [10000,20000],
and a ugidfw policy will ensure that they cannot access or even stat
files owned by each others:
ugidfw subject uid 10000:20000 object uid 10000:20000 !
uid_of_subject mode n
I think I will use mac_biba to protect the system integrity. With the
system labelled as biba/high and launchung Apache with a biba/low(low-
low) label we could certainly limit the impact of a root escalation.
Most system services would run being biba/high, with some notable
exceptions:
- Some log rotation scripts, which should be biba/equal
- Backup, which, of course, should be able to access the whole system.
It will also use mac_seeotheruids. And it would be great to have an
enhancement to mac_portacl. Limiting the usage of the listen() system
call.
There is great stuff in the MAC framework, indeed, and the
possibilities are endless. Best of that, security decisions go back
to the place they should have never abandoned: the operating system :)
I've just ordered the new O'Reilly book about FreeBSD and OpenBSD
security, but it seems that it doesn't mention the MAC framework at
all :(
Best regards,
Borja.
More information about the freebsd-security
mailing list