[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [linux-security] chattr +i and securelevel

[Mod: Subject changed and a part about modules removed. Also, if people have
comments, please email them directly to Jim and me - we will post a summary.
-- alex]

>>>  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.

	So.  I believe he was referring to dedicated servers, like
	ftp, web, nfs, db servers, and the like.  These boxes -- to 
	be considered reasonably secure -- should have not user
	level accounts on them -- just administrative accounts.

	I agree that there are many types of "production" machines
	where you don't want /etc/passwd and /etc/aliases, and 
	/etc/sendmail.cf (etc). to be immutable.  However I do
	recommend setting all libs, bins, kernels, man pages
	(groff macro trojans), and as many other files to
	immutable as you can.  Do this *even if you don't set

[Mod: Even on dedicated systems one needs to change passwords. The question
becomes more of a policy issue. Using a principle of the least priviledge,
one would expect that becoming superuser in order to just change a password
of one of the www admins is a not a good idea.

Also keep in mind that package manegers do not check for the immutable flags
which prevent easy package upgrades. -- alex]

>>> 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).

	I don't know about the code -- but I've chattr'd +i 
	and was unable to modify files as root.  So it has worked
	as *I* expected.

[Mod: from chattr(1) manual page:

	A file with the 'a' attribute set  can  only  be  open  in
       	append mode for writing.

	A  file with the 's' attribute cannot be modified: it can-
	not be deleted or renamed, no link can be created to  this
	file  and  no  data  can  be written to the file. Only the
	superuser can set or clear this attribute. -- alex]

> > 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.

	I suspect that you're wrong -- but I haven't looked at the 
	code.  Clearly an immutable file can be unprotected by 
	'chattr -i' by a root process -- until we have securelevel

> 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.)

	I disagree with both of these statements.  You could be 
	able to access the block and char devices according to 
	their permissions. 

	I also think that you should be able to create new b and
	c nodes according to the filesystem permissions.

	However I think that filesystems should not be mountable
	or remountable after securelevel is set.   At least
	there should be some mechanism by which mounting, remounting
	and unmounting is only supported according to the settings
	in /etc/fstab -- no override via command line parms.

	(Otherwise you can mount removable backup devices).
> 3) Disable module loading.
> 4) disable the chattr call for ext2fs. 

	I agree with this -- securelevel should prevent changes
	to the kernel memory space that would render the 
	system insecure.

> Only (4) is implemented right now. 

        Jim Dennis,
        Starshine Technical Services

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]