Hi. I'm forwarding my reply to an e-mail to freebsd-fs@.
I believe that when we have immutable flag set on an inode/znode it
shouldn't be possible to change its link count. We don't allow it for
unlink(2) (going from N to N-1), so we shouldn't allow to increase it
either.
This also have some security implications. In FreeBSD every base set-uid
binary has this immutable flag set. This prevents non-root users from
creating hardlinks to those binaries (even if they have write access to
Received: from [91.121.88.72] (helo=mail.dawidek.net)
by node002.open-zfs.net
with esmtp (HybridCluster distributed mail proxy)
(envelope-from <[email protected]>); Sun, 06 Oct 2013 08:23:40 -0000
a directory on the same file system, which without immutable flag is
possible). Creating those hardlinks may be profitable in case a new
security bug is found in such a binary. Even if administrator updates
the system, the user will still have access to the old, vulnerable
version.
The patch is here:
http://people.freebsd.org/~pjd/patches/zfs_vnops.c.8.patch
--
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://mobter.com
--- Begin Message -----X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 15, 2013 at 04:21:04PM -0700, Oleg Ginzburg wrote: > Hi >=20 > For some reason, creating hardlink within one UFS is failed for /usr/bin/= chfn=20 > with "operation not permitted" messages (other file is ok) This is because this file has 'schg' flag set. See: # ls -lo /usr/bin/chfn So this is difference in handling the 'schg' flag by UFS and ZFS. Received: from [91.121.88.72] (helo=mail.dawidek.net) by node002.open-zfs.net with esmtp (HybridCluster distributed mail proxy) (envelope-from <[email protected]>); Sun, 06 Oct 2013 08:23:40 -0000 I think I like UFS behaviour better. If regular user has write access to some directory, which is part of the same file system as the set-uid binary, then he can create hardlink to set-uid file and wait for a security to be found in this set-uid file. For example if /tmp/ and /usr/bin/ is on a single file system, I could create hardlink to chfn and other set-uid-root binaries and once security hole is found and even if system is updated, I still has access to the old set-uid-root binary to exploit. My suggestion would be to change ZFS behaviour to not allow hardlinks if the 'schg' flag is set. Something like this (not even compile-tested): http://people.freebsd.org/~pjd/patches/zfs_vnops.c.8.patch --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlI4msAACgkQForvXbEpPzTJCACg0Zdh3xLJKurYIbEg/X/fpmjD aCMAn0TG0dez6QSQQ2I9lif/4vy5J7Pz =Kwfr -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT--
--- End Message ---
pgpSnsz3vyRkM.pgp
Description: PGP signature
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
