Date: Sun, 18 Feb 96 21:22 WET From: uhclem@nemesis.lonestar.org (Frank Durda IV) To: hackers@freebsd.org Subject: Re: Is "immutable" supposed to be a good idea? Message-ID: <m0toMB5-000C7fC@nemesis.lonestar.org>
next in thread | raw e-mail | index | archive | help
[4]I vaguely remember that some of these flags were not supposed to [4]come into effect until the system went into multi-user mode.. [6]Bruce Evans <bde@zeta.org.au> writes: [6]No, see the init man page. Unfortunate. I think we should propose changing maintenance mode to run at level -1 (or make level 0 not enforce immutable), so that system recoveries can be performed. If your system is screwed-up and you are trying to restore it, nobody is going to be able to build a special run-maint-mode-at-level -1 kernel just for that occasion. Maintenance mode should be just that: all knobs exposed. [5]That would be OK *if* we waited until the system was all the way up [5]before going into that mode. In my case, fsck bombed and [5]offered me a sh. The system is apparently already in this [5]"secure" mode at that point. [6]By default, the system is always in insecure mode (security level -1; [6]use `sysctl kern.securelevel' to see the level). See above. The average sysadmin trying to recover a system is going to run into this nonsense again and again. [5]The same was true if I booted -s. By the time I got a shell, [5]the system was honoring the immut flag. [6]The immututable flags are always honoured. In secure mode, you can't [6]turn then off. In highly secure mode, you can write to the disk [6]directly to turn them off. Ok, then why as I stated in the very first posting was "Clearing /tmp" able to get rid of directories with files that were immutable that I had shifted into /tmp, but when I tried to do it myself in maintenance mode, I could not? If immutable is honored all the time, "Clearing /tmp" would also fail to get rid of these files, yes? Supposedly rc runs at level 0 or even level 1. /etc/rc shows nothing more powerful than a rm -rf command. How was it done? This is easily demonstratable. [5]If secure mode is something we turn on during the boot process, [6]You'd be really unhappy if we turned on secure mode :-). Undoubtedly, but we were not talking about what you call secure mode. I call that "very-secure mode" aka 2, and is not what was set here. What we had was a stock system, running pretty much with the off-the-CD configuration, ie, as secure as it is when we ship it. So this "very-secure mode" wasn't involved. Plain secure is "1". This thread started when I was simply trying to find out why maintenance mode or "FSCK CAN'T FIX IT, *YOU* FIX IT" mode from fsck (both 0 level in init-ese) can't be allowed to clean up botched files without having to have /usr mountable (that's where we hide chflags this week), and why standard recovery tools like restore, tar and cpio aren't able to report that their restores aren't actually restoring the files you expect them to restore. These questions remain completely unanswered. [4]I don't think these flags should be noticed till root decides to go [4]'secure' [5]I agree. [6]I disagree. The problem is that the immutable flags are set by default [6]on systems that will never run in secure mode. This provides some [6]protection against root doing stupid things, but very little security. Then why on Earth do we set them on the standard system? Why not have a "paranoid-permissions" file that you apply if you want your system to be unmaintainable, ie, more secure. [6]The immutable flags aren't much use for protecting binaries and [6]libraries anyway. Root can bypass them by moving the directory out of [6]the way. Only their contents is protected. Protecting contents is [6]useful for log files, but log files aren't immutable or append-only by [6]default. As I said in the original post, if it wasn't for being able to use "mv" in that fashion, I would have had to nuke the entire system to recover when the shared libraries got corrupted, and restore would not replace the immutable-but-corrupted copies, and wouldn't say that it wasn't doing this. Took quite a while to figure out that it was lying to me. If seems there is agreement after all: o The applications should either list the files that can't be restored or extracted, or SHOULD BE ABLE TO extract/restore over an immutable file in maintenance mode (Level 0) or some other set of criteria WITHOUT having to build a level -1 kernel first, o These and other files shouldn't be immutable in the first place on the bulk of the systems out there. Partly because it makes sysadmin more difficult, and partly because it provides false security. I'll fix restore to nuke & replace immutable files automatically *if* someone would guarantee that some approved version of the changes would be allowed into the release tree. (No point if there is some religious reason for not doing this.) I would prefer that the definition of maintenance mode be changed to not enforce immutable BY DEFAULT. If someone wants a more paranoid system, then that someone should be required to recompile and bump the maintenance mode security level up to 0, not the other way around. This immutable stuff can't possibly be a POSIX thing, so there should be no technical reason for fixing this, only religious reasons. Frank Durda IV <uhclem@nemesis.lonestar.org>|"What are we going to do tonite?" or uhclem%nemesis@rwsystr.nkn.net | Same thing we do every night - ^------(this is the fastest route)| Try to make Microsoft unhappy." or ...letni!rwsys!nemesis!uhclem | - Gatesy and the Brain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0toMB5-000C7fC>