Messages in this thread | | | Date | Wed, 30 Dec 2009 11:49:11 -0800 | From | Casey Schaufler <> | Subject | Re: A basic question about the security_* hooks |
| |
Kyle Moffett wrote: > On Mon, Dec 28, 2009 at 20:43, Casey Schaufler <casey@schaufler-ca.com> wrote: > >> Kyle Moffett wrote: >> >>> On Sat, Dec 26, 2009 at 14:50, Michael Stone <michael@laptop.org> wrote: >>> >>>> I'm willing to entertain pretty much any implementation or interface request >>>> which meets that goal and which implements the desired semantics. >>>> >>>> >>> If you aren't using SELinux at this time (and therefore have no >>> existing policy), then it's actually pretty straightforward >>> (relatively speaking) to set up for your particular goals. On top of >>> that, once you actually get the system set up, it's very easy to >>> extend your sandbox security model to additional processes, actions, >>> etc. >>> >>> [...] >>> >> I would be very surprised if the policy you've described actually >> covered all the bases. I would also be surprised if a functional >> policy that meets the needs described was considerably smaller than >> Lake Michigan. It's really easy to toss off the basics of what needs >> to be done, it's quite another to get the whole thing right. >> >> >>> If all you need is something much simpler, the policy >>> language is very flexible and easy to customize. >>> >>> >> I'm willing to bet all the beers you can drink in a sitting that >> the policy would be bigger than the proposed LSM. You can count that >> in either bytes or lines. >> > > If that bet's in Mountain Dew or "Bawls" energy drinks > (http://www.bawls.com/) instead of beer... then you've got a deal :-D >
Hee hee. A sitting doesn't last very long with those beverages.
> Here's a very fast first cut at such a policy. In this version I > actually completely ignore the type-enforcement mechanism, although if > you decide to start mediating file access then you may want to > reenable it. The policy is pretty straightforward and easy to read... > customizations would initially mostly be in the "constraint" rules. >
Wouldn't this policy prevent all processes from using the network, as opposed to the particular ones that need to be controlled? I can't claim to be the world's greatest policy expert, and I could have it wrong (it happens often enough) but wouldn't you need at least two labels, one for the restricted programs and one for the rest?
> The only thing I actually had to write was the base-policy.pp file. I > personally absolutely detest M4... so these particular files are > designed to be preprocessed with "cpp" instead. Those 3 ".h" files > are simply lists of the kernel's access vectors and such run through > "sed" to convert the "#" comments into "//" comments. > > I have a Makefile I've been using personally to build that policy, but > right now it's rather interdependent with my working environment, so > it may take me several days to find the time to extract it cleanly. > > Cheers, > Kyle Moffett >
| |