Hi Amon,
On Thu, Feb 24, 2005 at 09:28:38AM +0100, Amon Ott wrote:
> On Donnerstag 24 Februar 2005 01:55, Kurt Garloff wrote:
> > If you apply them (and I hope Linus will), capabilities is default
> > and you can replace that by loading an LSM. You can stack capability
> > on top of the primary LS
On Wed, 2005-02-23 at 13:37 -0800, Crispin Cowan wrote:
> You are confused. It is Secure Computing Corporation that holds patents
> that threaten SELinux
> http://www.securecomputing.com/pdf/Statement_of_Assurance.pdf
The NSA made a statement in response to that statement a long time ago,
and in
On Donnerstag 24 Februar 2005 01:55, Kurt Garloff wrote:
> On Mon, Feb 21, 2005 at 11:19:16AM +0100, Amon Ott wrote:
> > Without rechecking the current state: At least the last time I
> > checked, the hardwired kernel capabilities were explicitely
disabled
> > when LSM got switched on. You had t
Hi Amon,
On Mon, Feb 21, 2005 at 11:19:16AM +0100, Amon Ott wrote:
> > -> 5. Posix Capabilities Without Stacking Support
> >
> > I don't get the point of these claims.
> > The LSM framework currently has full support for dynamic and
> > logic-changeable POSIX.1e capabilities, using the capable()
El mié, 23-02-2005 a las 14:07 -0800, Crispin Cowan escribió:
> If that is what you meant, then we had no issue.
>
> It looked like you were referring to Immunix because, in the quoted
> text, one paragraph only discussed Immunix (by name) and then the
> subsequent paragraph just said "them" and
Lorenzo Hernández García-Hierro wrote:
El mié, 23-02-2005 a las 13:37 -0800, Crispin Cowan escribió:
Lorenzo Hernández García-Hierro wrote:
You are confused. It is Secure Computing Corporation that holds patents
that threaten SELinux
http://www.securecomputing.com/pdf/Statement_of_Assurance.pd
El mié, 23-02-2005 a las 13:37 -0800, Crispin Cowan escribió:
> Lorenzo Hernández García-Hierro wrote:
> You are confused. It is Secure Computing Corporation that holds patents
> that threaten SELinux
> http://www.securecomputing.com/pdf/Statement_of_Assurance.pdf
>
> Immunix has never threatene
Lorenzo Hernández García-Hierro wrote:
Also, it was a pretty good thing from them this piece of work.
Think that they investors may dislike the model they followed when the
merge happened, anyways, and as an example, I pretty ignore those
patents claims,for example, think that Type Enforcement (TE)
--- Amon Ott <[EMAIL PROTECTED]> wrote:
> On Montag 21 Februar 2005 18:50, Casey Schaufler
> wrote:
> >
> > --- Lorenzo Hernández García-Hierro
> <[EMAIL PROTECTED]>
> > wrote:
> >
> >
> > > > There are cases where Linux DAC and MAC cannot
> > > live happily together,
> > > > because Linux DA
On Montag 21 Februar 2005 18:50, Casey Schaufler wrote:
>
> --- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]>
> wrote:
>
>
> > > There are cases where Linux DAC and MAC cannot
> > live happily together,
> > > because Linux DAC is too limited.
> >
> > Agreed.
>
> OKay, I'll bite. MAC and
--- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]>
wrote:
> > There are cases where Linux DAC and MAC cannot
> live happily together,
> > because Linux DAC is too limited.
>
> Agreed.
OKay, I'll bite. MAC and DAC are seperate.
How is it that (the limited nature of) the DAC
behavior makes
El lun, 21-02-2005 a las 11:19 +0100, Amon Ott escribió:
> Hi folks,
>
> this is a late reply, because I was away for a week
Hey ao, I was looking for you last week, nice to know you're back
again ;)
>
> Documentation is a general problem in all projects, not only the
> kernel. For me, this ha
Hi folks,
this is a late reply, because I was away for a week.
On Dienstag 15 Februar 2005 23:38, Lorenzo Hernández García-Hierro
wrote:
> The purpose of this email is not re-opening the old flame on the
> anti-LSM "pleas" that were subject of many discussion and
> disappointments in certain dev
On Wed, 16 Feb 2005 07:52:51 PST, Casey Schaufler said:
> The advice given by the NSA during our B1
> evaluation was that is was that in the case
> above was that the MAC check should be done
> first (because it's more important) and
> because you want the audit record to report
> the MAC failure
--- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]>
wrote:
> ... but think it's main
> shortcoming is that it cuts
> performance
Ya'know, I keep hearing this assertion, but
the evidence of actual system implementations
that have been measured to determine this
"performance impact" is that t
--- [EMAIL PROTECTED] wrote:
> Many auditing policies require an audit event to be
> generated if the operation
> is rejected by *either* the DAC (as implemented by
> the file permissions
> and possibly ACLs) *or* the MAC (as implemented by
> the LSM exit). However,
> in most (all?) cases, the
On Wed, 2005-02-16 at 08:29, Lorenzo HernÃndez GarcÃa-Hierro wrote:
> Yes, there are many cases that apply to such scenario and context, this
> may be worth to work on, but think it's main shortcoming is that it cuts
> performance and adds further overlapping to the DAC checks, that should
> be the
El mar, 15-02-2005 a las 23:21 -0500, [EMAIL PROTECTED] escribió:
> On Tue, 15 Feb 2005 23:38:09 +0100, Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?=
> =?ISO-8859-1?Q?Garc=EDa-Hierro?= said:
>
> > Yes, and that's noticed from the "official" documentation.
> > But, who says that we can't place auditing fa
On Tue, 15 Feb 2005 23:38:09 +0100, Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?=
=?ISO-8859-1?Q?Garc=EDa-Hierro?= said:
> Yes, and that's noticed from the "official" documentation.
> But, who says that we can't place auditing facilities inside the
> existing hooks? or even file system linking related tw
Hi,
The purpose of this email is not re-opening the old flame on the
anti-LSM "pleas" that were subject of many discussion and
disappointments in certain developers and user groups.
I will try to answer some of those in as much as possible organized
manner, without any personal opinion being show
20 matches
Mail list logo
