Date: Mon, 19 Feb 1996 17:53:28 +1100 From: Bruce Evans <bde@zeta.org.au> To: hackers@FreeBSD.org, uhclem@nemesis.lonestar.org Cc: wollman@FreeBSD.org Subject: Re: Is "immutable" supposed to be a good idea? Message-ID: <199602190653.RAA16444@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
[Quoting lots for Garrett to see]
>[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.
Actually, the security handling does change for multi-user mode if
kern.securelevel is 0, but the default is kern.securelevel = -1.
>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
This was done 18 months ago:
===
RCS file: /a/ncvs/src/sys/kern/kern_sysctl.c,v
Working file: /sys/kern/kern_sysctl.c
head: 1.59
...
----------------------------
revision 1.6
date: 1994/08/10 02:41:09; author: wollman; state: Exp; lines: +2 -2
Change default security level to -1, so that users don't get bitten by
upcoming makefile change.
----------------------------
===
>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.
Securelevel -1 isn't such a mode.
>[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
^ not
>[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.
"Clearing /tmp" should fail if there are system-immutable files in /tmp.
It fails here.
>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.
They don't report restoral because they fail with an "Operation not
permitted" error. They should report this (tar does). They fail
because the schg bit is set. The schg bit is set because someone
considered it important for them to fail. I probably overemphasizied
the security aspects in my previous mail. The point of schg'ing
/usr/lib/libc.so.* is mainly to protect it from overwrites.
>[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.
For most cases it's because 4.4lite sets them and no one has cared enough
to make them easy to manage or actually work. For libc.so.* and ld.so,
they are set to prevent overwrites.
>[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.
So the most serious bug is that `restore' doesn't report errors?
>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,
I think that the extract/restore/copy programs should continue to know
nothing about the file flags (except perhaps to generate better error
messages) and that chflags(8) should be put in /sbin and on the standard
fixit disk.
>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.
No. If you don't want any immutable files, then don't set any immutable
flags. Perhaps this should be the default even for security-related files.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602190653.RAA16444>