Re: link() security

[Hank Leininger]

On 2002-04-13, xystrus <[e-mail]> wrote:

> On Sat, Apr 13, 2002 at 05:59:54PM +0100, Alan Cox wrote:
> > > http://openwall.com.  Work based on Solar Designer's Openwall patch
> > > has been brought forward to more recent 2.4 and 2.5 kernels.  Both
> > > the following projects implement the Openwall secure link feature:
> > > 
> > > http://grsecurity.net
> > > http://lsm.immunix.org
> > > 
> > > This can break some applications that make assumptions wrt. link(2)
> > > (Courier MTA for example).
> > 
> > How practical is it to make this a mount option and to do so cleanly ?

...I like the mount option idea, will explore for my next patch... ;)

> Perhaps two options: one to allow creation of the link only when the
> UIDs match; and the other to allow the link when GIDs match, to keep
> Courier happy?

Well, if UIDs match there's no problem.  From Openwall (2.2.20 fs/namei.c
at/near line 1312):
        if (current->fsuid != inode->i_uid &&
		...other tests

I've been using a modification[1] of the Openwall patch to allow the GID
case just as you describe, for some in-house secure drop-directory where
multiple daemons share a GID to play in their queue directory.  I've never
used courier but it sounds like that may work w/this change as well.  From
2.2.20-hap-5 fs/namei.c line 1318:
#ifdef CONFIG_SECURE_NOTSOMUCH
	/*
	 * Let users hard link to files in their group.
	 */
	    current->fsgid != inode->i_gid &&
#endif

This works well, but the CONFIG_ option name is chosen for a reason; this
has some side effects which may not be desirable.  Allowing GID matches
will often result in users being able to hard link to each others files, on
systems where users are all in group 'users' by default (and users have
files in non-0700 directories).

I know the grsecurity guys have ported most of both Openwall and HAP to
2.4, not positive if they carried over the NOTSOMUCH option but it'd be
simple to add.  Keep in mind all this violates POSIX standards so isn't
likely to ever be in-kernel, but the patches should be maintained for some
reasonably large value of $forever.

[1] http://www.theaimsgroup.com/~hlein/hap-linux/, the patch has many
    other things, just search for CONFIG_SECURE_NOTSOMUCH.

--
Hank Leininger <[e-mail]>