Re: [PATCH] Filesystem linking protections

["Lorenzo Hernández García-Hierro" <lorenzo@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 2606 bytes --]

El lun, 07-02-2005 a las 16:45 -0500, Valdis.Kletnieks@vt.edu 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 <lorenzo@gnu.org> 
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 189 bytes --]