Hardlinks...

[Paweł Jakub Dawidek]

Hey...

Why I can made hardlink to file that I'm not owner?

Simple example why I think that only owner should have permission to create
hardlinks to his files.

First.
leila:root:~# ls -l /root/very-secret-file
-rw------ 1 root wheel 3011 13 Lut 16:47 /root/very-secret-file

leila:evil-hacker:~> ln /root/very-secret-file ~/whatsthis

<I need remove it fast!!!>
leila:root:~# rm -f /root/very-secret-file

Yes, I know that evil-hacker can't read this file but...
He can't read it NOW, but in a future he can break in and read it.

I know that we can check this with 'st_nlink' or use -P with rm, but...

Or tell me when this feature can help.

--
Paweł Jakub Dawidek
Network Administrator.
Am I Evil? Yes, I Am.

[Doug White]

On Mon, 8 Apr 2002, [ISO-8859-2] Paweł Jakub Dawidek wrote:

> Simple example why I think that only owner should have permission to create
> hardlinks to his files.
>
> First.
> leila:root:~# ls -l /root/very-secret-file
> -rw------ 1 root wheel 3011 13 Lut 16:47 /root/very-secret-file
>
> leila:evil-hacker:~> ln /root/very-secret-file ~/whatsthis
>
> <I need remove it fast!!!>
> leila:root:~# rm -f /root/very-secret-file

I see you forgot to 'ls -l' the resultant link ... you'll find that it has
the same permissions and ownership as the original file. Oops.

(this is not a great example. I've rearranged the commands for
illustration purposes which is why the history #s bounce around.)

wade,ttyp3,~,11>id
uid=1000(dwhite) gid=1000(dwhite) groups=1000(dwhite), 0(wheel),
5(operator), 68(dialer), 88(mysql), 998(cvs)
wade,ttyp3,~,17>ls -l /root/bin
total 2
-rwxr-xr-x 2 root wheel 186 Feb 14 2001 copykeys.sh*
-rwxr-xr-x 1 root wheel 186 Feb 15 2001 copykeysfd.sh*
wade,ttyp3,~,13>ln /root/bin/copykeys.sh foobaz.sh
wade,ttyp3,~,15>ls -l foobaz.sh
-rwxr-xr-x 2 root wheel 186 Feb 14 2001 foobaz.sh*
wade,ttyp3,~,16>ls -l /root/bin/copykeys.sh
-rwxr-xr-x 2 root wheel 186 Feb 14 2001 /root/bin/copykeys.sh*

Doug White | FreeBSD: The Power to Serve
dwh...@resnet.uoregon.edu | www.FreeBSD.org

To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message

[Michael Smith]

> On Mon, 8 Apr 2002, [ISO-8859-2] Paweł Jakub Dawidek wrote:

> =

> > Simple example why I think that only owner should have permission to =

create
> > hardlinks to his files.

...
> I see you forgot to 'ls -l' the resultant link ... you'll find that it =

has
> the same permissions and ownership as the original file. Oops.

You misunderstand the original poster's complaint.

The issue is that a non-owner can cause the owner's file to remain alive =

even after the owner has deleted it. Hence the comment about "later =

breakin".

You could also use this technique to maliciously exhaust a user's quota, =

by linking to their temporary files. I'm not sure what the standards =

have to say about this, but I don't much like the current behaviour.

-- =

To announce that there must be no criticism of the president,
or that we are to stand by the president, right or wrong, is not
only unpatriotic and servile, but is morally treasonable to =

the American public. - Theodore Roosevelt

[Kurt J. Lidl]

On Mon, Apr 08, 2002 at 11:41:44AM -0700, Michael Smith wrote:
> You could also use this technique to maliciously exhaust a user's quota,

> by linking to their temporary files. I'm not sure what the standards

> have to say about this, but I don't much like the current behaviour.

The truely paranoid ftruncate the file size to zero if the link count
is larger than one.

-Kurt

[Dan Nelson]

In the last episode (Apr 08), Kurt J. Lidl said:
> On Mon, Apr 08, 2002 at 11:41:44AM -0700, Michael Smith wrote:
> > You could also use this technique to maliciously exhaust a user's
> > quota, by linking to their temporary files. I'm not sure what the
> > standards have to say about this, but I don't much like the current
> > behaviour.
>
> The truely paranoid ftruncate the file size to zero if the link count
> is larger than one.

.. or even if isn't, as someone might link it just before you delete
it. An attacker can still exhaust your inode quota with 0-length
files.

I wonder if there is any reason to allow arbitrary hardlinking; maybe
only allow linking of files you currently have read access to? Only
files that you own? Only allow root to hardlink? How paranoid do you
want to be? :) It could always be another sysctl knob.

--
Dan Nelson
dne...@allantgroup.com

[David Malone]

On Mon, Apr 08, 2002 at 02:49:15PM -0500, Dan Nelson wrote:
> .. or even if isn't, as someone might link it just before you delete
> it. An attacker can still exhaust your inode quota with 0-length
> files.
>
> I wonder if there is any reason to allow arbitrary hardlinking; maybe
> only allow linking of files you currently have read access to? Only
> files that you own? Only allow root to hardlink? How paranoid do you
> want to be? :) It could always be another sysctl knob.

I once wrote a patch to stop people making hardlinks to a file
unless they were root or the file's owner. I ran with it for a bit
and never noticed it being triggered.

It probably should be a filesystem mount option, but we're out of
them until the new mount code comes into use.

David.

[Paweł Jakub Dawidek]

On Mon, Apr 08, 2002 at 11:41:44AM -0700, Michael Smith wrote:

+> You could also use this technique to maliciously exhaust a user's quota,
+> by linking to their temporary files. I'm not sure what the standards
+> have to say about this, but I don't much like the current behaviour.
+>
Yes. And look on this part of foldinfo.c from procmail:

{ if(stbuf.st_uid!=uid|| /* recipient not owner */
!(stbuf.st_mode&S_IWUSR)|| /* recipient can write? */
S_ISLNK(stbuf.st_mode)|| /* no symbolic links */
(S_ISDIR(stbuf.st_mode)? /* directories, yes, hardlinks */
!(stbuf.st_mode&S_IXUSR):stbuf.st_nlink!=1)) /* no */
/*
* If another procmail is about to create the new
* mailbox, and has just made the link, st_nlink==2
*/

As You can see, this is not good idea to use procmail when anyone can made
a hardlink to my mailbox.

[Terry Lambert]

Paweł Jakub Dawidek wrote:
> =

> Hey...
> =

> Why I can made hardlink to file that I'm not owner?

> =

> Simple example why I think that only owner should have permission to cr=
eate
> hardlinks to his files.

Among other things, so that you can use programs that use
file locks based on link count.

-- Terry

[Terry Lambert]

Michael Smith wrote:
> You misunderstand the original poster's complaint.
>
> The issue is that a non-owner can cause the owner's file to remain alive

> even after the owner has deleted it. Hence the comment about "later

> breakin".
>
> You could also use this technique to maliciously exhaust a user's quota,

> by linking to their temporary files. I'm not sure what the standards

> have to say about this, but I don't much like the current behaviour.

I think that making the links in temporary directories should
not be allowed, by dint of the t bit in the user of the
directory in which the file is being created.

I think the problem with someone else making a link to my
file and keeping it around is an issue of access controls
to the file itself, and not really a problem: e.g. if you
want to avoid it, don't rely on obscurity, and don't permit
exterior access to the files.

Actually, people have complained about not having a "flink(2)"
call to create a directory entry for an open file. I think
if this were there, then the problem would be genuine; but
without it, it's a matter of controlling access to the files.

I wouldn't be opposed to a patch that prevented creation of
links to files you don't own, if the 't' bit were set on the
wource or destination directory, but which would permit the
operation otherwise.

I think a patch that disallowed it entirely would break
/var/spool/lock based locking. 8-(.

-- Terry

[Dan Nelson]

In the last episode (Apr 08), Terry Lambert said:
> Michael Smith wrote:
> > You misunderstand the original poster's complaint. The issue is
> > that a non-owner can cause the owner's file to remain alive even
> > after the owner has deleted it. Hence the comment about "later
> > breakin".
> >
> > You could also use this technique to maliciously exhaust a user's
> > quota, by linking to their temporary files. I'm not sure what the
> > standards have to say about this, but I don't much like the current
> > behaviour.
>
> I think that making the links in temporary directories should not be
> allowed, by dint of the t bit in the user of the directory in which
> the file is being created.

So the user creates /tmp/zzz/ , chmod 0's /tmp/zzz, and sticks his
link in there.

> I think the problem with someone else making a link to my file and
> keeping it around is an issue of access controls to the file itself,
> and not really a problem: e.g. if you want to avoid it, don't rely on
> obscurity, and don't permit exterior access to the files.

But the question is "should execute permission on a directory imply
link permission for all files in the directory?"

If so, we'll have to move master.passwd and spwd.db out of etc, then.
Into /etc/shadow/ (chmod 0) maybe? If the user can cd into the
directory the file is in, he can link it elsewhere. You don't even
need read permission on the directory.

This might be a bit paranoid, as a problem only exists if the user
later is able to gain root to access the files he stashed away earlier.
The most paranoid admin would have to make sure that no world-writable
directories exist on the same partition as files he wants to keep
secure.

> I think a patch that disallowed it entirely would break
> /var/spool/lock based locking. 8-(.

But for UUCP locking, you're linking a tempfile that you just created
to the true lock name. You are linking from a file you own, which
would be allowed even under the strictest lockdown of link. I think
it'd work fine.

--
Dan Nelson
dne...@allantgroup.com

[Terry Lambert]

Dan Nelson wrote:
> > I think the problem with someone else making a link to my file and
> > keeping it around is an issue of access controls to the file itself,
> > and not really a problem: e.g. if you want to avoid it, don't rely on
> > obscurity, and don't permit exterior access to the files.
>
> But the question is "should execute permission on a directory imply
> link permission for all files in the directory?"

If you can copy it, you should be allowed to link it; if you
can't, then you shouldn't.

> If so, we'll have to move master.passwd and spwd.db out of etc, then.
> Into /etc/shadow/ (chmod 0) maybe? If the user can cd into the
> directory the file is in, he can link it elsewhere. You don't even
> need read permission on the directory.

The ability to link to files you don't have read access to
is rather ridiculous. The patch that was proposed, though
shot you in the head, even if you do have read access (e.g.
as in a "LCK..tty0" file).

It's arguable that "/" and "/usr" themselves should be
mounted read-only, and that /tmp should be "elsewhere",
though, so this could be portrayed as an administrative
issue, not a kernel issue.

> > I think a patch that disallowed it entirely would break
> > /var/spool/lock based locking. 8-(.
>
> But for UUCP locking, you're linking a tempfile that you just created
> to the true lock name. You are linking from a file you own, which
> would be allowed even under the strictest lockdown of link. I think
> it'd work fine.

Think "lock override due to ``kill -0'' giving ESRCH instead
of EPERM or success".

-- Terry

[Crist J. Clark]

On Mon, Apr 08, 2002 at 09:13:12PM -0700, Terry Lambert wrote:
[snip]

> It's arguable that "/" and "/usr" themselves should be
> mounted read-only,

It's not very practical to have / read-only on a truely multi-user
(the only time this linking stuff is much of an issue) 4-STABLE
system. The two main reasons being /etc/master.passwd, et al, and the
problems with a read-only /dev. It takes extensive customizations and
kludges to get this to work.
--
Crist J. Clark | cjc...@alum.mit.edu
| cjc...@jhu.edu
http://people.freebsd.org/~cjc/ | c...@freebsd.org

[Bob Bishop]

Hi,

At 11:41 08/04/02 -0700, Michael Smith wrote:
> > On Mon, 8 Apr 2002, [ISO-8859-2] Paweł Jakub Dawidek wrote:
> >

> > > Simple example why I think that only owner should have permission to=

> create
> > > hardlinks to his files.

>...
> > I see you forgot to 'ls -l' the resultant link ... you'll find that it=

has
> > the same permissions and ownership as the original file. Oops.
>

>You misunderstand the original poster's complaint.
>
>The issue is that a non-owner can cause the owner's file to remain alive
>even after the owner has deleted it. Hence the comment about "later
>breakin".
>
>You could also use this technique to maliciously exhaust a user's quota,
>by linking to their temporary files. I'm not sure what the standards
>have to say about this, but I don't much like the current behaviour.

If you have any permissions on the file, you can prolong its life without a=

link simply by having a process open it. This is 'better' as a DOS because=

it's harder to spot.

--
Bob Bishop +44 (0)118 977 4017
r...@gid.co.uk fax +44 (0)118 989 4254

[Terry Lambert]

"Crist J. Clark" wrote:
> On Mon, Apr 08, 2002 at 09:13:12PM -0700, Terry Lambert wrote:
> [snip]
>
> > It's arguable that "/" and "/usr" themselves should be
> > mounted read-only,
>
> It's not very practical to have / read-only on a truely multi-user
> (the only time this linking stuff is much of an issue) 4-STABLE
> system. The two main reasons being /etc/master.passwd, et al, and the
> problems with a read-only /dev. It takes extensive customizations and
> kludges to get this to work.

It depends. If this is a truly multiuser environment, then
you are probably getting your authentication from NIX or RADIUS.

It's really arguable that /etc should be a nullfs mount off of
somewhere else and/or variable information belongs in "var" or
some other place...

Sun has been able to do this since 1988 or so (at least).

-- Terry

[Terry Lambert]

Bob Bishop wrote:
> If you have any permissions on the file, you can prolong its life without a

> link simply by having a process open it. This is 'better' as a DOS because

> it's harder to spot.

Plus you can start a bunch of processes, dup the thing, an then
pass it around amoung the processes so that they *all* have a
reference, and it's difficult to impossible to kill them all...

Of course, the most expedient fix is "don't give these idiots
accounts on your machine".

8^p.

-- Terry

[Julian Elischer]

On Tue, 9 Apr 2002, Terry Lambert wrote:

> "Crist J. Clark" wrote:
> > On Mon, Apr 08, 2002 at 09:13:12PM -0700, Terry Lambert wrote:
> > [snip]
>

> It depends. If this is a truly multiuser environment, then
> you are probably getting your authentication from NIX or RADIUS.
>
> It's really arguable that /etc should be a nullfs mount off of
> somewhere else and/or variable information belongs in "var" or
> some other place...
>
> Sun has been able to do this since 1988 or so (at least).
>

As terry knows of course, the Interjet
had the following /etc/symlinks: (excuse linewrap)
lrwxrwxrwx 1 root wheel 20 Mr 28 2001 crontab@ ->
/writable/system/crontab
lrwxrwxrwx 1 root wheel 18 Mr 28 2001 group@ ->
/writable/system/group
lrwxrwxrwx 1 root wheel 22 Mr 28 2001 localtime@ ->
/writable/system/localtime
lrwxrwxrwx 1 root wheel 3 Mr 28 2001 malloc.conf@ -> >>A
lrwxrwxrwx 1 root wheel 26 Mr 28 2001 master.passwd@ ->
/writable/system/master.passwd
lrwxrwxrwx 1 root wheel 19 Mr 28 2001 pwd.db@ ->
/writable/system/pwd.db
lrwxrwxrwx 1 root wheel 28 Mr 28 2001 resolv.conf@ ->
/writable/server/dns/resolv.conf
lrwxrwxrwx 1 root wheel 31 Mr 28 2001 sendmail.cf@ ->
/writable/mail/sendmail/sendmail.cf
lrwxrwxrwx 1 root wheel 20 Mr 28 2001 spwd.db@ ->
/writable/system/spwd.db

the single root+usr partition is mounted read-only.

[Terry Lambert]

Julian Elischer wrote:
> As terry knows of course, the Interjet
> had the following /etc/symlinks: (excuse linewrap)
> lrwxrwxrwx 1 root wheel 20 Mr 28 2001 crontab@ ->
> /writable/system/crontab
> lrwxrwxrwx 1 root wheel 18 Mr 28 2001 group@ ->
> /writable/system/group

[ ... ]

> the single root+usr partition is mounted read-only.

Yes, but appealing to a product I had something to do with,
even if that organization wasn't mine in particular, makes
a much less powerful argument.

The other thing that's a bit painful about that argument
is that the symlinks failed to operate as expected for
the master.passwd, if the / was mounted read/write. I
count this as a bug in the password database generation
code, but it should be noted that it can be a problem (e.g
the symlink is renamed to the backup, and the replacement
file is created in /etc; it does the right thing, if the
symlink is read-only, though...).

8-(.

[Crist J. Clark]

On Tue, Apr 09, 2002 at 04:42:52PM -0700, Terry Lambert wrote:
> Julian Elischer wrote:
> > As terry knows of course, the Interjet
> > had the following /etc/symlinks: (excuse linewrap)
> > lrwxrwxrwx 1 root wheel 20 Mr 28 2001 crontab@ ->
> > /writable/system/crontab
> > lrwxrwxrwx 1 root wheel 18 Mr 28 2001 group@ ->
> > /writable/system/group
>
> [ ... ]
>
> > the single root+usr partition is mounted read-only.
>
> Yes, but appealing to a product I had something to do with,
> even if that organization wasn't mine in particular, makes
> a much less powerful argument.
>
> The other thing that's a bit painful about that argument
> is that the symlinks failed to operate as expected for
> the master.passwd, if the / was mounted read/write. I
> count this as a bug in the password database generation
> code, but it should be noted that it can be a problem (e.g
> the symlink is renamed to the backup, and the replacement
> file is created in /etc; it does the right thing, if the
> symlink is read-only, though...).

Exactly, you can't use symlinks with the passwd(1) and pwd_mkdb(8)
commands as they stand. The commands will bail when they try to create
a temporary file in /etc, /etc/pw.XXXXXX if /etc is read-only. If
/etc is not read-only, the symlinks will get removed and the files
actually written in /etc.

--
Crist J. Clark | cjc...@alum.mit.edu
| cjc...@jhu.edu
http://people.freebsd.org/~cjc/ | c...@freebsd.org

To Unsubscribe: send mail to majo...@FreeBSD.org

[Terry Lambert]

"Crist J. Clark" wrote:
> > file is created in /etc; it does the right thing, if the
> > symlink is read-only, though...).
>
> Exactly, you can't use symlinks with the passwd(1) and pwd_mkdb(8)
> commands as they stand. The commands will bail when they try to create
> a temporary file in /etc, /etc/pw.XXXXXX if /etc is read-only. If
> /etc is not read-only, the symlinks will get removed and the files
> actually written in /etc.

"it does the right thing, if the symlink is read-only, though..."

That includes if it's on a read-only FS... 8-).

-- Terry

[Michael Sinz]

"Crist J. Clark" wrote:
>
> On Mon, Apr 08, 2002 at 09:13:12PM -0700, Terry Lambert wrote:
> [snip]
>
> > It's arguable that "/" and "/usr" themselves should be
> > mounted read-only,
>
> It's not very practical to have / read-only on a truely multi-user
> (the only time this linking stuff is much of an issue) 4-STABLE
> system. The two main reasons being /etc/master.passwd, et al, and the
> problems with a read-only /dev. It takes extensive customizations and
> kludges to get this to work.

Actually, with minimal work in the rc.diskless* files, we have a
very workable, large-scale system with / as Read-Only. In fact,
only /dev and /var are read-write (well, in testing we also have
a /sewer for coredumps) /dev and /var are local RAM disks (and /tmp
points are /var/tmp)

One of these days I will want to write up some of what we did. It
really is rather nice to have a whole cluster of machines sharing the
same install and the boot server.

--
Michael Sinz ---- Worldgate Communications ---- ms...@wgate.com
A master's secrets are only as good as
the master's ability to explain them to others.

[Crist J. Clark]

On Thu, Apr 18, 2002 at 11:18:30AM -0400, Michael Sinz wrote:
> "Crist J. Clark" wrote:
> >
> > On Mon, Apr 08, 2002 at 09:13:12PM -0700, Terry Lambert wrote:
> > [snip]
> >
> > > It's arguable that "/" and "/usr" themselves should be
> > > mounted read-only,
> >
> > It's not very practical to have / read-only on a truely multi-user
> > (the only time this linking stuff is much of an issue) 4-STABLE
> > system. The two main reasons being /etc/master.passwd, et al, and the
> > problems with a read-only /dev. It takes extensive customizations and
> > kludges to get this to work.
>
> Actually, with minimal work in the rc.diskless* files, we have a
> very workable, large-scale system with / as Read-Only. In fact,
> only /dev and /var are read-write (well, in testing we also have
> a /sewer for coredumps) /dev and /var are local RAM disks (and /tmp
> points are /var/tmp)

It may be easier to fit it in with a diskless configuration. One of
the problems is that in a "normal" (i.e. not diskless) stuff in /dev
is used before you get at chance to mount something over /dev. And
that may or may not be a problem. But the diskless stuff is run so
early in the boot process, it seems like it should be easier to manage
that.

> One of these days I will want to write up some of what we did.

That would be interesting.

--
Crist J. Clark | cjc...@alum.mit.edu
| cjc...@jhu.edu
http://people.freebsd.org/~cjc/ | c...@freebsd.org

To Unsubscribe: send mail to majo...@FreeBSD.org