Re: A basic question about the security_* hooks

[Casey Schaufler <casey@schaufler-ca.com>]

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
>