Re: Thoughts on the "No Linux Security Modules framework" old claims
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 any event, the patents in question have expired AFAICS. -- Stephen Smalley <[EMAIL PROTECTED]> National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thoughts on the "No Linux Security Modules framework" old claims
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 then talked about patents. > There was no mention of SCC. > > So even if you meant SCC, the casual reader only saw "Immunix" followed > by "patents", and would infer the obvious. Yes, my fault. I hope this will let readers out of any possible confusion, again, sorry for any inconveniences, wasn't my intention to create confusion around Immunix. At least from my side, I don't have fights nor bad relationships with anybody from Immunix, but also I just know a very few people from there. Cheers, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: Thoughts on the "No Linux Security Modules framework" old claims
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.pdf Immunix has never threatened any open source project with patent infringement. You got it wrong, I was talking about SCC, not Immunix, relating the TE patent, anyways, it's my fault to don't refer to SCC instead of "the enterprise" which could lead to confusion.I apologize for that. 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 then talked about patents. There was no mention of SCC. So even if you meant SCC, the casual reader only saw "Immunix" followed by "patents", and would infer the obvious. Crispin -- Crispin Cowan, Ph.D. http://immunix.com/~crispin/ CTO, Immunix http://immunix.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thoughts on the "No Linux Security Modules framework" old claims
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 threatened any open source project with patent > infringement. You got it wrong, I was talking about SCC, not Immunix, relating the TE patent, anyways, it's my fault to don't refer to SCC instead of "the enterprise" which could lead to confusion.I apologize for that. > Please get your facts straight before accusing someone of a serious act > like that. I'm sure I do, haven't accused someone, AFAIK. Cheers, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: Thoughts on the "No Linux Security Modules framework" old claims
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) is patented and before SELinux got in mainline the enterprise with rights on the patent made a public announcement about their "opening" and "for-free" use of their patented model. 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 threatened any open source project with patent infringement. Please get your facts straight before accusing someone of a serious act like that. Crispin -- Crispin Cowan, Ph.D. http://immunix.com/~crispin/ CTO, Immunix http://immunix.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thoughts on the "No Linux Security Modules framework" old claims
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 whenever possible. The > team advised us that if we didn't do the MAC > check first we would have a tough row to hoe > explaining the design decision and an even > tougher time explaining that the audit of > MAC criteria had been met. Fine advice, if the LSM exits had in fact been structured that way. But the LSM hooks are where they are, and as a result not useful for auditing. As others noted, the current 2.6 kernel *does* have a separate audit framework (although it will still report DAC failures in preference to MAC failures). I admit having no good idea how to solve that issue, other than having the audit framework do a dummy LSM call to see if a MAC failure would have been reported as well if it's an audited syscall. But that's still quite high on the bletcherous scale pgpAQFB8jRcqp.pgp Description: PGP signature
Re: Thoughts on the "No Linux Security Modules framework" old claims
--- 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 there is no difference except in contrived cases. In contrived cases the performance is better if you do the "special" checks first. > and adds further overlapping to the DAC > checks, that should > be the first ones being called (as most times they > do) and then apply > the LSM basis, so, post-processing will be only > required if the DAC > checks get in override or passed, without adding > too-much overhead to > the current behavior. No. There are a number of reasons, including audit and nearline storage issues that make it important to do the special checks first. Some access control schemes may not work if the Classic DAC check is done first. > So, I just agree partially, but yes, maybe modifying > the DAC checks > themselves and add what-ever-else helper function to > handle by-default > auditing in certain operations could be interesting. I remain a advocate of authoritative hooks. > I think it could be worthy to have a roadmap in a > wiki or even talk > about a one, trying to write it, so, we all could > know what needs to be > improved and done, getting a higher percentage of > mainline-accepted > approaches. Sigh. = Casey Schaufler [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thoughts on the "No Linux Security Modules framework" old claims
--- [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 DAC check is made *first*, > and the LSM exit isn't > even called if the DAC check fails. As a result, if > you try to open() a file > and get -EPERM due to the file permissions, the LSM > exit isn't called and > you can't cut an audit record there. 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 whenever possible. The team advised us that if we didn't do the MAC check first we would have a tough row to hoe explaining the design decision and an even tougher time explaining that the audit of MAC criteria had been met. = Casey Schaufler [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thoughts on the "No Linux Security Modules framework" old claims
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 first ones being called (as most times they do) and then apply > the LSM basis, so, post-processing will be only required if the DAC > checks get in override or passed, without adding too-much overhead to > the current behavior. > > So, I just agree partially, but yes, maybe modifying the DAC checks > themselves and add what-ever-else helper function to handle by-default > auditing in certain operations could be interesting. Audit is being handled by a separate audit framework, not by LSM. There is already support in the Linux 2.6 kernel for auditing at syscall exit (thereby guaranteeing that you capture the final return value in all cases), with the ability of an LSM to enable such auditing for a particular event from its hook functions. Further, there is ongoing work (see the linux-audit mailing list) for a set of audit-related hooks that will allow auditing based on object identity and the requested mode separate from any particular LSM. -- Stephen Smalley <[EMAIL PROTECTED]> National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thoughts on the "No Linux Security Modules framework" old claims
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 facilities inside the > > existing hooks? or even file system linking related tweaks? > > 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 DAC check is made *first*, and the LSM exit isn't > even called if the DAC check fails. As a result, if you try to open() a file > and get -EPERM due to the file permissions, the LSM exit isn't called and > you can't cut an audit record there. 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 first ones being called (as most times they do) and then apply the LSM basis, so, post-processing will be only required if the DAC checks get in override or passed, without adding too-much overhead to the current behavior. So, I just agree partially, but yes, maybe modifying the DAC checks themselves and add what-ever-else helper function to handle by-default auditing in certain operations could be interesting. I think it could be worthy to have a roadmap in a wiki or even talk about a one, trying to write it, so, we all could know what needs to be improved and done, getting a higher percentage of mainline-accepted approaches. Cheers, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: Thoughts on the "No Linux Security Modules framework" old claims
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 tweaks? 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 DAC check is made *first*, and the LSM exit isn't even called if the DAC check fails. As a result, if you try to open() a file and get -EPERM due to the file permissions, the LSM exit isn't called and you can't cut an audit record there. pgpIg1VbKxmpP.pgp Description: PGP signature
