From: "Lorenzo Hernández García-Hierro" <lorenzo@gnu.org>
To: Valdis.Kletnieks@vt.edu
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Chris Wright <chrisw@osdl.org>
Subject: Re: [PATCH] Filesystem linking protections
Date: Mon, 07 Feb 2005 20:34:33 +0100 [thread overview]
Message-ID: <1107804873.3754.232.camel@localhost.localdomain> (raw)
In-Reply-To: <200502071914.j17JEbjQ018534@turing-police.cc.vt.edu>
[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]
El lun, 07-02-2005 a las 14:14 -0500, Valdis.Kletnieks@vt.edu escribió:
> On Mon, 07 Feb 2005 19:57:06 +0100, Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?= =?ISO-8859-1?Q?Garc=EDa-Hierro?= said:
>
> > This patch adds two checks to do_follow_link() and sys_link(), for
> > prevent users to follow (untrusted) symlinks owned by other users in
> > world-writable +t directories (i.e. /tmp), unless the owner of the
> > symlink is the owner of the directory, users will also not be able to
> > hardlink to files they do not own.
>
> This should be done using the LSM framework. That's what it's *THERE* for.
> I've previously posted an LSM that does these checks (and a few others), it
> should be in the archives.
vSecurity also implements this and many other "ported" features from
OpenWall and grSecurity.
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.
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.
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.
Cheers,
--
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 --]
next prev parent reply other threads:[~2005-02-07 19:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-07 18:57 [PATCH] Filesystem linking protections Lorenzo Hernández García-Hierro
2005-02-07 19:12 ` Chris Wright
2005-02-07 19:40 ` Lorenzo Hernández García-Hierro
2005-02-07 20:00 ` Chris Wright
2005-02-07 19:43 ` John Richard Moser
2005-02-07 20:05 ` Chris Wright
2005-02-07 22:29 ` John Richard Moser
2005-02-07 22:47 ` Chris Wright
2005-02-08 2:10 ` John Richard Moser
2005-02-07 19:14 ` Valdis.Kletnieks
2005-02-07 19:34 ` Lorenzo Hernández García-Hierro [this message]
2005-02-07 21:45 ` Valdis.Kletnieks
2005-02-07 22:00 ` Lorenzo Hernández García-Hierro
2005-02-07 22:13 ` Valdis.Kletnieks
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1107804873.3754.232.camel@localhost.localdomain \
--to=lorenzo@gnu.org \
--cc=Valdis.Kletnieks@vt.edu \
--cc=chrisw@osdl.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox