lkml.org 
[lkml]   [2003]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: hard links create local DoS vulnerability and security problems
Date
On Monday 24 November 2003 11:57, Jakob Lell wrote:
> Hello
>
> On Monday 24 November 2003 18:14, Richard B. Johnson wrote:
> > On Mon, 24 Nov 2003, Jakob Lell wrote:
> > > Hello,
> > > on Linux it is possible for any user to create a hard link to a file
> > > belonging to another user. This hard link continues to exist even if
> > > the original file is removed by the owner. However, as the link still
> > > belongs to the original owner, it is still counted to his quota. If a
> > > malicious user creates hard links for every temp file created by
> > > another user, this can make the victim run out of quota (or even fill
> > > up the hard disk). This makes a local DoS attack possible.
[snip]
> >
> > A setuid binary created with a hard-link will only work as a setuid
> > binary if the directory it's in is owned by root. If you have users
> > that can create files or hard-links within such directories, you
> > have users who either know the root password already or have used
> > some exploit to become root. In any case, it's not a hard-link
> > problem
>
> Setuid-root binaries also work in a home directory.
> You can try it by doing this test:
> ln /bin/ping $HOME/ping
> $HOME/ping localhost

What? You allow users write access to a filesystem containing privileged
applications????

You really shouldn't do that. Any filesystem a user has write access to should
be mounted nosgid.

> > > To solve the problem, the kernel shouldn't allow users to create hard
> > > links to
> > > files belonging to someone else.
> >
> > No. Users must be able to create hard links to files that belong
> > to somebody else if they are readable. It's a requirement.
>
> If this is REALLY neccessary, it might be possible to prevent hard links to
> setuid binaries.
> Regards
> Jakob

You would also have to consider setgid binaries.

It also means that you have to read the inode of the source file. Right now,
only the contents of directory have to be read (the file search for the inode
number).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.110 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site