Re: [cobalt-users] "Chattr +i" on inetd.conf & the GUI

[flash22@xxxxxxx]

On Tue, 21 Aug 2001, Scott F wrote:

> > I seriously thought "chattr -i" was all that 
> > was needed to remove "chattr" settings from a file, 
> 
> >
> >>It is, and that should tell you something 
> >>about how useless chattr is when
> >>you don't have the machine setup to use it ;) 
> >>So don't play with it, if you had managed to 
> >>get it to work you would be in real trouble, 
> >>as a machine setup to use immutable file 
> >>attributes will not let even root turn
> >>them off again, that's the ENTIRE point of them ;)
> 
> Ummmm, what would be the point of "chattr -i" if even
> someone with root priv can't turn it off? 

That *is* the point, if someone breaks in and gets a root shell, they
still can't modify the file....

> 
> I'm pretty sure these machines will allow you to set
> chattr on any file.. I've done so on numerous security
> related files, and they can't be touched, even as user
> root unless you first issue the "chattr -i" command on

And what's the point? If the file is owned by root and not writable by
users, then only root can change it anyhow, making it +i doesn't do
anything else....

> the file. Personally, I keep chattr on my hosts.deny
> and hosts.allow files, as well as my firewall and the
> file that holds the IP's of blocked ghouls from my
> firewall to name a few. If Jr. managed to obtain

WHY? these files are only writab;e by root to start with, who else can
modify them?

> access to one of my systems, I certainly would want to
> make it as difficult as possible to him/her to modify
> several important (security) files, and he/she's not
> going to do so with chattr set unless they get root...

What do you think Jr's goal is to start with? Of course he's gonna get
root./

> I use this command with all my boxes as I'm a true
> believer in security by layers.

Ya, complicate the machine with more and more junk untill it reaches the
point where even you don't understand the security, then you feel safe
because even you can't imagine any ways to get into the machine -/

Ok, not trying to flame here, but i really think you missed the point of
the immutable attributes on the filesystem.

The idea is to prevent files from getting compromised *even when someone
gets root access* . The way this works is, you make the important files,
like the shadow password and security monitoring files +i, then you set a
kernel flag that makes the system refuse to allow them to be changed back
with chattr -i. Now the files are truel 'immutable' even root can't
compromise them.

The way you are using it, it doesn't do anything chmod couldn't
do...except perhaps confuse the rare kidde scripter who doesn't have a
knowdegable hacker coaching him on irc...

After that , to actually make changes to the files, you have to reboot to
clear the kernel flag , -i them, make any necessary changes under
controlled conditions (eg you reboot without network access) and then you
reset the flag.

At least that's the idea, i rarely see anyone using the feature however.

> ...But when it comes to using the
> GUI, it doesn't matter, it just returns the message
> "/etc/inetd.conf is locked" regardless if you issue
> "chattr -i /etc/inetd.conf" on the file prior to
> trying to use the GUI..

Well, you need to keep in mind the GUI isn't aware of extended file system
attributes in any way at all...so fiddling with chattr will cause all
kinds of odd things to happen...

The GUI may well be accessing other files, even if they aren't obviously
related to inetd.conf, if *any* of them are unreadable it will be
unhappy..Don't assume too much about GUI error messages, i have seen it
confused from time to time about what really went wrong....

 Make sure you havn't also set one of the other attributes...

> 
> Thanks for your guy's input!

Taco isn't 'my guy' btw, The nice fellow works for Cobalt EMEA :)

I just putter along as best i can...

gsh