Date: Fri, 16 Feb 1996 14:36:25 +0200 From: Dmitry Kohmanyuk <dk@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? Message-ID: <199602161236.OAA24477@dog.farm.org>
next in thread | raw e-mail | index | archive | help
In article <inj.2-3122c4dd-55ea@bee.cs.kiev.ua> 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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602161236.OAA24477>