El lun, 07-02-2005 a las 16:45 -0500, [EMAIL PROTECTED] escribió: > On Mon, 07 Feb 2005 20:34:33 +0100, Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?= > =?ISO-8859-1?Q?Garc=EDa-Hierro?= said: > > > But It's better to give users a "secure-by-default" status, at least on > > those parts that don't affect negatively the stability or the > > performance itself. > > It's still policy, and should be put someplace where users can manage it. > You're changing the behavior from what POSIX specifies, and that's in general > a no-no for mainline kernel code.
A sysctl can be a good option, creating a CTL_SECURITY and then registering stuff under it, but this requires to have the kernel hackers agree with implementing a new security suite and such. In short, re-inventing the wheel. > Like an LSM, which happens to be there so users can impose policy without > making any code changes to the kernel. Implementing a policy that results in > non-POSIXy behavior in an LSM is perfectly OK.. ;) It's currently made in vSecurity :) > > The LSM hook call is before the check, so, LSM framework still has the > > control over it, until it releases the operation giving control back to > > the standard function. > > Right.. Which means LSM can stop that particular attack even faster than > your patch.. ;) At least I don't interfere with LSM, so, if no LSM hook adds it's own security checks, then it gets used. > > If users must rely on LSM or other external solutions for applying basic > > security checks (as the framework itself only provides the way to apply > > them, the checks need to be implemented in a module), then we are making > > them unable to be protected using the "default" configuration. > > You're making the very rash assumption that a hard-coded one-size-fits all > "default" that behaves differently than POSIX is suitable for all sites, > including sites that run software that gets broken by this change, and > things like embedded systems where it's not a concern at all, and sites that > already implement some *other* system to ensure that it's not an issue (for > instance, by using an SELinux policy...) Good point, then the solution is to make it config-dependent, and that's a thing that kernel hackers seem to dislike. Lemme know what's the final thought on this, so, I could work out it and give what you want, without time loss and we all can feel happy with it :) Cheers and thanks for the comments, -- 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
