Re: Dailydave Digest, Vol 23, Issue 15

[tobaccofarm <phaceton () gmail com>]

"If she
went to the wrong website that wanted to exploit her browser, it would
only be able to do things from the security context you allowed for her
browser."

And there's no buffer overflow posssibility?
SElinux doesn't protect against all sorts of buffer overflows?

kind regards,

P.T.L.J.Harmsen
On 4/25/05, dailydave-request () lists immunitysec com
<dailydave-request () lists immunitysec com> wrote:
> Send Dailydave mailing list submissions to
>         dailydave () lists immunitysec com
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.immunitysec.com/mailman/listinfo/dailydave
> or, via email, send a message with subject or body 'help' to
>         dailydave-request () lists immunitysec com
>
> You can reach the person managing the list at
>         dailydave-owner () lists immunitysec com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Dailydave digest..."
>
> Today's Topics:
>
>    1. Re: Media Excitement! (Cody Hatch)
>    2. Re: Media Excitement! (robert () dyadsecurity com)
>    3. Re: Media Excitement! (robert () dyadsecurity com)
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 24 Apr 2005 13:31:45 -0600
> From: Cody Hatch <bytejump () gmail com>
> Subject: Re: [Dailydave] Media Excitement!
> To: pageexec () freemail hu
> Cc: dailydave <dailydave () lists immunitysec com>
> Message-ID: <b56bb3a70504241231397bfd0e () mail gmail com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I completely agree with pageexec here. RBAC is good - no doubt - but
> the difficulty of implementing a proper and secure policy seems almost
> insurmountable. Foolproof doesn't exis because fools have proven far
> too clever in the past.
>
> It seems to me to be a better approach to use PaX, grsecurity, and
> systrace to make the kernel and applications behave appropriately
> rather than build a monolithic set of policies that govern the
> permissions (roles) of users and processes.
>
> Don't get me wrong - I see the benefits or RBAC - but I view
> complexity as the law of averages working against you - the more
> complex something gets, the more likely it is that mistakes will be
> made.
>
> Regards,
> Cody
>
> On 4/22/05, pageexec () freemail hu <pageexec () freemail hu> wrote:
> > On 22 Apr 2005 at 10:09, robert () dyadsecurity com wrote:
> > > The goal here wasn't to say "This one is more secure than that one".
> > > It's to say "We have this level of sensitivity and require these
> > > particular security mechanisms, and need this assurance level as to the
> > > effectiveness of the security mechanisms".  Basically, choose the right
> > > technology for your environment.
> >
> > i understood this much ;-), the real question is, which of the solutions
> > in the mentioned URL gives *appropriate assuarance* against exploitation
> > (remember the original question about alternatives to patching)? based
> > on my experience and instinct, none of them does (EAL 4 is little more
> > than a joke), but i'd like to be *proven* wrong.
> >
> > > > side question, which one of those didn't have security patches since
> > > > their evaluation?
> > >
> > > I believe every product listed has had patches since their evaluation.
> > > As I pointed out though in an earlier post, the containment of the
> > > compromise, or rather the inherent ability to limit intrusion should
> > > be designed into the TCB, not bolted on afterwards.
> >
> > does any of the mentioned products at that URL contain a compromise
> > (thinking of kernel bugs)? or to be more precise, does any real-life
> > policy (since any deployed MAC system implements one) exclude the
> > compromise of the TCB? if not (which would match my experience), then
> > what's the real point (of getting certified at EAL<7)?
> >
> > _______________________________________________
> > Dailydave mailing list
> > Dailydave () lists immunitysec com
> > https://lists.immunitysec.com/mailman/listinfo/dailydave
>
> ------------------------------
>
> Message: 2
> Date: Sun, 24 Apr 2005 21:48:43 -0700
> From: robert () dyadsecurity com
> Subject: Re: [Dailydave] Media Excitement!
> To: pageexec () freemail hu
> Cc: dailydave <dailydave () lists immunitysec com>
> Message-ID: <20050425044843.GA23861 () 5002 rapturesecurity org>
> Content-Type: text/plain; charset=us-ascii
>
> pageexec () freemail hu(pageexec () freemail hu)@Sat, Apr 23, 2005 at 03:02:18AM +0100:
> > i understood this much ;-), the real question is, which of the solutions
> > in the mentioned URL gives *appropriate assuarance* against exploitation
> > (remember the original question about alternatives to patching)? based
> > on my experience and instinct, none of them does (EAL 4 is little more
> > than a joke), but i'd like to be *proven* wrong.
>
> You have to remember that the EAL is the assurance of the implementation.
> IE how well thought out, formally documented/analyzed, etc was their
> implementation of the selected Protection Profiles.  You can be EAL 4+
> .. but if the only protection profile you're building for is CAPP, you
> had significantly different design goals than the OS's that tried to
> implement CAPP, RBAC, and LSPP, (the new SKPP) etc.
>
> The rest of your post will be more meaningful to answer once you spend
> more time with a working implementation.  SE Linux or Trusted Solaris
> would be good choices to start with, or even start by simply reading the
> Orange book.  It may change your perception of what's possible and what
> the designers were trying to accomplish.
>
> Robert
>
> --
> Robert E. Lee
> CEO, Dyad Security, Inc.
> W - http://www.dyadsecurity.com
> E - robert () dyadsecurity com
> M - (949) 394-2033
>
> ------------------------------
>
> Message: 3
> Date: Sun, 24 Apr 2005 22:09:22 -0700
> From: robert () dyadsecurity com
> Subject: Re: [Dailydave] Media Excitement!
> To: Cody Hatch <bytejump () gmail com>
> Cc: dailydave <dailydave () lists immunitysec com>
> Message-ID: <20050425050922.GB23861 () 5002 rapturesecurity org>
> Content-Type: text/plain; charset=us-ascii
>
> Cody Hatch(bytejump () gmail com)@Sun, Apr 24, 2005 at 01:31:45PM -0600:
> > It seems to me to be a better approach to use PaX, grsecurity, and
> > systrace to make the kernel and applications behave appropriately
>
> These steps may or may not prove useful in decreasing the success of
> certain attack vectors, but they do not represent the same goals of
> projects like SE Linux.
>
> > Don't get me wrong - I see the benefits or RBAC - but I view
> > complexity as the law of averages working against you - the more
> > complex something gets, the more likely it is that mistakes will be
> > made.
>
> I would argue that discretion in the hands of the novice is more
> complicated than using a MAC/DTE machine for pre-agreed usage.  If you
> wanted to, you could set up an SE Linux box for a secretary that could
> use an Email program, Web Browser, Printer, and Word Processor.  If she
> went to the wrong website that wanted to exploit her browser, it would
> only be able to do things from the security context you allowed for her
> browser.  It wouldn't have access to her sensitive documents, or her gpg
> keys, or your internal network, etc.  She would be able to open those
> dirty attachments from email and not get compromised with a DDoS zombie
> client.  She would have these protections because what is and what is
> not allowed is clearly defined in the policy, and the policy is
> enforced.
>
> Policy weaknesses can expose you to vulnerability, but that's because
> computers do what you tell them to do, which isn't always what you want
> them to do. That's why you leave discretion in the capable hands of
> those qualified to make policies.
>
> Also, RBAC actually makes systems easier to manage in a DTE environment.
> We're working on an SE Linux policy set that we'll eventually share back
> that will show case the use of RBAC.  But that won't be out until
> sometime after Black Hat.
>
> Robert
>
> --
> Robert E. Lee
> CEO, Dyad Security, Inc.
> W - http://www.dyadsecurity.com
> E - robert () dyadsecurity com
> M - (949) 394-2033
>
> ------------------------------
>
> _______________________________________________
> Dailydave mailing list
> Dailydave () lists immunitysec com
> https://lists.immunitysec.com/mailman/listinfo/dailydave
>
> End of Dailydave Digest, Vol 23, Issue 15
> *****************************************
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
https://lists.immunitysec.com/mailman/listinfo/dailydave