--- Tetsuo Handa <[EMAIL PROTECTED]> wrote:
> Hello.
>
> Casey Schaufler wrote:
> > Fine grained capabilities are a bonus, and there are lots of
> > people who think that it would be really nifty if there were a
> > separate capability for each "if" in the kernel. I personally
> > don't see need
On Nov 7, 2007 2:11 PM, Tetsuo Handa <[EMAIL PROTECTED]> wrote:
> Hello.
>
> Casey Schaufler wrote:
> > Fine grained capabilities are a bonus, and there are lots of
> > people who think that it would be really nifty if there were a
> > separate capability for each "if" in the kernel. I personally
>
Hello.
Casey Schaufler wrote:
> Fine grained capabilities are a bonus, and there are lots of
> people who think that it would be really nifty if there were a
> separate capability for each "if" in the kernel. I personally
> don't see need for more than about 20. That is a matter of taste.
> DG/UX
--- Cliffe <[EMAIL PROTECTED]> wrote:
> As good an idea POSIX capabilities might be,
Now that's a refreshing comment. Thank you.
> not all security problems
> can be solved with a bitmap of on/off permissions.
There are people (I'm not one of them) who figure that you
can solve all the securi
As good an idea POSIX capabilities might be, not all security problems
can be solved with a bitmap of on/off permissions.
Peter Dolding wrote:
"AppArmor profile denies all network traffic to a specific
application" Ok why should AppArmor be required to do this. Would it
not be better as as pa
Lets on paper do what Crispin Cowan said to be a good stacker apparmor
become purely restrictive and modules like it. This will explain were
stacking ends up dead meat.
Most people don't notice that the default system is there Posix
Capabilities. So effectively just by changing apparmor you hav
Crispin Cowan wrote:
Simon Arlott wrote:
On Tue, October 30, 2007 07:14, Cliffe wrote:
And while I acknowledge that many of these layers are currently buried
within the kernel (netfilter...) they are security layers which in many
cases would probably make sense as stackable security
Simon Arlott wrote:
> On Tue, October 30, 2007 07:14, Cliffe wrote:
>
>> And while I acknowledge that many of these layers are currently buried
>> within the kernel (netfilter...) they are security layers which in many
>> cases would probably make sense as stackable security modules.
>>
>> Makin
--- Crispin Cowan <[EMAIL PROTECTED]> wrote:
> Al Viro wrote:
> > On Tue, Oct 30, 2007 at 03:14:33PM +0800, Cliffe wrote:
> >
> >> Defense in depth has long been recognised as an important secure design
> >> principle. Security is best achieved using a layered approach.
> >>
> > "Layere
On Tue, October 30, 2007 07:14, Cliffe wrote:
> And while I acknowledge that many of these layers are currently buried
> within the kernel (netfilter...) they are security layers which in many
> cases would probably make sense as stackable security modules.
>
> Making the interface static forces ma
Al Viro wrote:
> On Tue, Oct 30, 2007 at 03:14:33PM +0800, Cliffe wrote:
>
>> Defense in depth has long been recognised as an important secure design
>> principle. Security is best achieved using a layered approach.
>>
> "Layered approach" is not a magic incantation to excuse any bit of s
Al Viro wrote:
On Tue, Oct 30, 2007 at 03:14:33PM +0800, Cliffe wrote:
Defense in depth has long been recognised as an important secure design
principle. Security is best achieved using a layered approach.
"Layered approach" is not a magic incantation to excuse any bit of snake
oil.
On Tue, Oct 30, 2007 at 03:14:33PM +0800, Cliffe wrote:
> Defense in depth has long been recognised as an important secure design
> principle. Security is best achieved using a layered approach.
"Layered approach" is not a magic incantation to excuse any bit of snake
oil. Homeopathic remedies m
Defense in depth has long been recognised as an important secure design
principle. Security is best achieved using a layered approach.
On a single system it makes sense to have a layered approach such as:
Standard DAC (where users are in control of permissions)
Some form of user-based non-DAC (
14 matches
Mail list logo
