From owner-freebsd-security  Sun Jun  2 13:16:00 1996
Return-Path: owner-security
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id NAA07589
          for security-outgoing; Sun, 2 Jun 1996 13:16:00 -0700 (PDT)
Received: from who.cdrom.com (who.cdrom.com [204.216.27.3])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA07582
          for <freebsd-security@freebsd.org>; Sun, 2 Jun 1996 13:15:57 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by who.cdrom.com (8.6.12/8.6.11) with ESMTP id NAA03570
          for <freebsd-security@freebsd.org>; Sun, 2 Jun 1996 13:15:54 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id FAA04887; Mon, 3 Jun 1996 05:59:38 +1000
Date: Mon, 3 Jun 1996 05:59:38 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199606021959.FAA04887@godzilla.zeta.org.au>
To: coredump@nervosa.com, freebsd-security@freebsd.org
Subject: Re: [linux-security] ext2fs file attributes -- denial-of-service attack (fwd)
Sender: owner-security@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>Could this have any impact on our implementation of ext2fs?

Not directly.  The ext2fs append and immutable flags have ufs semantics
under FreeBSD, and the other ext2fs flags have no effect under FreeBSD.
However, the ext2fs semantics seem to be the same as the the ufs ones
for the common flags, so the bug report may have an impact on CSRG's
implementation of ufs :-).

There are some implementation bugs in our ext2fs that reduce the problem
for our ext2fs.  ufs has both user and system immutable and append flags
but ext2fs (apparently) has only a system immutable flag and a shared
append flag.  The ext2fs flags are each mapped to the (user|system)
combination of ufs flags, and ext2fs uses ufs_setattr() and ufs_getattr()
without special handling for the ext2fs flags.  Thus it is possible to
fchflags() the flags in the vnode to an unrepresentable value and see
the wrong value using fstat(), but denial of service attacks and writing
to your own append-only files are prevented by the system append flag
being set.

>Any user is permitted to set any file attribute other than `immutable'
>on files they own.  In particular, an unprivileged user can set the
>`append-only' flag.  To do this merely requires the ability to execute
>arbitrary code -- the flag is set by an ioctl(2) call.  The usual way
>to set these flags is by use of the chattr(8) command.

4.4Lite has a cleaner implementation involving the chflags(2) and
fchflags(2) syscalls, and a more naturally named chflags(8) command.

>The effects of the append-only flag being set on a file are

>o No process, even with privileges, may open the file other than in
>  append mode.  The file cannot be truncated.

>o No process, even with privileges, may use link(2), unlink(2) or
>  rename(2) on the file.

>The flag can be set on a directory in the same way, in which case

>o No process, even with privileges, may use rename(2) or rmdir(2) on
>  the directory.

>o No process, even with privileges, may use rename(2), rmdir(2) or
>  unlink(2) on any entry in the directory.

>The only differences between the effects of the append-only flag and
>the immutable flag are that an append-only file may be appended to
>(whereas an immutable file cannot be opened for writing at all), and an
>append-only directory may have new entries added to it (whereas an
>immutable directory can't be modified at all).

This is all the same as in 4.4Lite.

>Note that the immutable
>flag, because of its extensive effects, can only be set by a privileged
>process, but the append-only attribute, with most of the same effects,
>can be set by the owner of the file in question, even if unprivileged.

4.4Lite has a separate immutable for users, so the denial of service
problems (if any) apply to the immutable flag too.  It has a separate
append flag for users, so the semantics are clearer and fixing the
problem by restricting access is equivalent to dropping support for
the user flags.

>Obviously there are denial-of-service attacks based on this.  The most
>obvious attack is to create a very large file in /tmp and make it
>append-only -- any root-run program intended to clear /tmp will fail
>unless it knows to remove the flag.  Even if it does know, there is a

Root had better know how to clear flags using chflags -R.  FreeBSD's
`rm' has been hacked to unconditionally turn off the user append and
immutable flags before attempting removals.  4.4Lite2's rm still fails
to remove user-append/immutable files.

Bruce