| From: | LI Xin <delphij@xxxxxxxxxxx> |
| Date: | Sun, 05 Nov 2006 23:20:27 +0800 |
Simon 'corecode' Schubert wrote: > Victor Balada Diaz wrote: >> On Sat, Nov 04, 2006 at 06:26:39PM -0800, Matthew Dillon wrote: >>> dillon 2006/11/04 18:26:39 PST >>> >>> DragonFly src repository >>> >>> Modified files: >>> bin/rm rm.1 rm.c Log: >>> Sync our rm -P option with OpenBSD - if the file has a hardlink count >>> greater then one do not overwrite it or remove it, and issue a >>> warning. >> >> If you use -P you know what you're doing, or at least if you use -f >> with -P. DragonFly by default allows any user to do a hard link to >> a file he doesn't own, so if you really want to delete file contents >> you must be able to. > > I think in any case, rm -P should remove setuid/gid bits from the file, > because if your intention originally was to completely remove the file, > and suddenly it (and its links) stay arround, still with setuid set, it > could be quite bad. > > The situation I have in my head is (courtesy of vbd): > > /home symlink to /usr/home > > eviluser$ ln /usr/bin/lpr /usr/home/eviluser/tmp/lpr-faulty > # yay. lpr-faulty is setuid root > > # security advisory: vuln in lpr > root# rm -P /usr/bin/lpr > root# # eh? warning? whatever, never find out where the link is > root# rm /usr/bin/lpr > root# install -mode 1555 /root/fixed-lpr /usr/bin/lpr > > # one month later > eviluser$ exploit ~/tmp/lpr-fault While I think this is purely the administrator's fault (one should first do chmod 000 *before* trying to fix the files), it might be advisable that there is some way to get the old behavior, if the administrator really what he is doing. This can be archived by counting -P's numbers (e.g. -PP for old behavior), or by determining whether -f is specified, as we did on FreeBSD. For now I tend to agree that -P should not exist in the first place, though... Cheers, -- Xin LI <delphij@xxxxxxxxxxx> http://www.delphij.net/ FreeBSD - The Power to Serve!
Attachment:
signature.asc
Description: OpenPGP digital signature