From owner-freebsd-hackers Fri Feb 16 07:47:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA11221 for hackers-outgoing; Fri, 16 Feb 1996 07:47:07 -0800 (PST) Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id HAA11203 for ; Fri, 16 Feb 1996 07:46:35 -0800 (PST) Received: from uucp3.UU.NET by relay5.UU.NET with SMTP id QQadel28482; Fri, 16 Feb 1996 10:46:17 -0500 (EST) Received: from uanet.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Fri, 16 Feb 1996 10:46:18 -0500 Received: by crocodil.monolit.kiev.ua; Fri, 16 Feb 96 16:17:44 +0200 Received: (from dk@localhost) by dog.farm.org (8.6.11/dk#3) id OAA24477; Fri, 16 Feb 1996 14:36:25 +0200 Date: Fri, 16 Feb 1996 14:36:25 +0200 From: Dmitry Kohmanyuk Message-Id: <199602161236.OAA24477@dog.farm.org> To: uhclem@nemesis.lonestar.org (Frank Durda IV) Cc: freebsd-hackers@freebsd.org Subject: Re: Is "immutable" supposed to be a good idea? Newsgroups: cs-monolit.gated.lists.freebsd.hackers Reply-To: dk+@ua.net X-Newsreader: TIN [version 1.2 PL2] Sender: owner-hackers@freebsd.org Precedence: bulk In article you wrote: > Some of the /stand directory files were also missing, but "mt" and > "restore" still worked, so I took the latest backup and used it to restore > /usr/lib. But guess what I found once the restore was complete? Thanks > to those lovely "immutable" flags on the shared libraries, the restore had > no effect on them! So after the restore was completed, the garbled files > were still there. Hmmm... I run 2.0.5, and have moved my system to different drives several times, so perhaps I have lost them... But my understanding that file flags work only in security level 0 or above, and the default security level is -1, and can be raised only by hand by `sysctl -w kern.securelevel=0'. >From my understanding, none of /etc/* scripts changes securelevel. It's up to sysadmin to enable this ( and I really _love_ to make my /kernel /sbin/init /bin/sh and perhaps some others immutable). > Of course, /stand/rm would not work to get rid of these files, chflags > wasn't around anymore (and it probably relies on the shared libraries anyway > since it isn't in /stand). Finally, (thankfully) I realized I could it's bad chflags is not in the /stand/'s crunch, IMHO. but since init uses -1 by default (contrary to man page which says it's 0 single-user and 1 multi-user; see /sys/kern/kern_sysctl.c, not the /sys/conf/param.c as man page for init suggests). > "/stand/mv" the entire /usr/lib directory out of the way, delete all I > could out of the copy, then restore /usr/lib from tape. Then I could > get to fixing the rest of the damage with tools that worked. that's bug ;-) if you set immutable on /usr/lib, you're stuck, I guess. > I noted some recent discussion about the "hole" created by being able to > move a directory containing an immutable file elsewhere. Thank goodness > for this "hole"! Don't plug it! I probably would have had to nuke the > entire system otherwise. you probably just have to boot kernel with securelevel of -1. is `fixit' kernel of this kind? > If restore isn't really doing a restore, then it would be Really Nice > if it said so, something like "I can't replace this file", or "%d files > could not be restored". Personally, if this immutable thing has to stay > (of which currently I see no benefit except to prevent people running > as root from doing stupid things and to prevent people running as root > or in maintenance mode from doing smart things), I would rather see > restore, tar, cpio, rm and any other system recovery tools all be able to > replace files with these flags, if the utility is running suid==root. IMHO, that's kernel feature to _disallow_ anyone to change immutable flags. And you can't decrement securelevel once it's risen, and if your kernel is immutable and you don't have access to the console/machine and can't boot a different kernel (boot floppy, different kernel name on boot prompt) you cannot hack your lovely 4.4 box. That was the whole point of CSRG immultable files design, I beleive ;-) > Strangely, one of the directories with these immutable files was moved into > /tmp to get it out of the way. On the next reboot, the normal system start > was able to get rid of all of the files. That seems curious. What has > rc got that I haven't got? I think it was securelevel of -1 not changed. again, I'm referring to 2.0.5 here hoping 2.1 haven't changed default securelevel... hack your kernel/init if it does. -- "I want to die peacefully in my sleep like my grandfather. Not screaming in terror like his passengers."