[1313] in linux-security and linux-alert archive
[linux-security] Re: BOUNCE: Re: Chattr +i and securelevel
daemon@ATHENA.MIT.EDU (Rogier Wolff)
Thu Nov 21 05:54:52 1996
To: alex@bach.cis.temple.edu (Alexander O. Yuriev)
Date: Thu, 21 Nov 1996 09:49:53 +0100 (MET)
Cc: woody@mcp-low.csh.rit.edu, R.E.Wolff@bitwizard.nl
In-Reply-To: <199611210406.XAA13543@bach.cis.temple.edu> from "Alexander O. Yuriev" at Nov 20, 96 11:06:05 pm
From: R.E.Wolff@bitwizard.nl (Rogier Wolff)
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
Alexander O. Yuriev wrote:
>
> Your message dated: Wed, 20 Nov 1996 18:04:39 EST
> > >has anyone played with the securelevel variable in the kernel and the
> > >immutable flags in the ext2 file system?
> >
> > Yes, and its actualy quite nice.
> >
> > >The sysctrl code seems to allow the setting of the flag
> > >only by init (PID=1) and only upwards (0->1, etc).
> > >[ Mod: If you have a look at securelevel code you can see that at this
> > >moment the only process that can change securelevel is init.
> >
> > Look closer. It's an exported symbol that any module can link
> > against (and alter?).
>
> Lets not even talk about modules - modules are running in a kernel mode
> which means that they can violate any and all privs.
>
> > To be honest, I haven't gone through the trouble
> > of coding a module yet, but compiled kernels with securelevel=1 works. :)
> > It's a nice lock+key function when you're looking to immute or append-
> > only special files. (Immuting /etc/passwd on production machines is a
> > simple security measure that saves hours of time... trust me.)
>
> Which will prevent passwd, chfn and chsh work.... So no, I won't trust you.
>
> > I did,
> > however, notice a couple of broken things in the immutable area, namely,
> > the execption for root is tested before the immutable kick-out code.
> > The main reason I use the immute/append tags are so processes running
> > as root CANT alter certain files. (Ie a human has to un-tag the files
> > before they can be altered).
>
> Correct me if I am wrong but is not chattr a wrapper against a system call?
> Who will prevent a program running as root to issue such call? Essentially,
> I think we can agree that there is no way to prevent a smart attacker from
> penetrating a system, you can only make your system harder to penetrate than
> a system of your neighbour.
The securelevel code simply isn't finished. I suspect Remi Card had the
feeling he wanted a securelevel variable, stuck it in in his area of the
code (ext2fs) and put in a little code in the sysctl as an example of how
this variable might be changed.
When securelevel <> 0, you should
1) Disable writing/reading block devices. (i.e. you can no longer use mtools
for floppies)
2) disable writing/reading char devices, except maybe mouse and serial
ports. (At least kmem should be disabled, which is a char device.)
3) Disable module loading.
4) disable the chattr call for ext2fs.
Only (4) is implemented right now.
Roger.
>
> Best wishes,
> Alex
>
