Chattr is a command used to set / unset file attributes in Linux. Using chattr it is possible to make a file immutable. That is, even a root user will be prohibited from deleting the file.

The trick lies in setting the appropriate attribute for the file.

chattr command is similar to the attrib command in DOS but much more powerful and flexible.

To prevent anyone - even a root user - from deleting a file, you set the immutable bit of the file using the chattr command as follows -

# chattr +i filename

The immutable bit option +i can only be set by the root user. So either you should have root priviledges or you need to use sudo to execute the command.

Once the +i bit is set, even root user won't be able to delete or tamper with the file.

To unset the immutable flag -

# chattr -i filename

Every file in Linux have a number of attributes associated with it. The immutable bit attribute being just one of them. To see what all attributes are set for a particular file, you run the lsattr command as follows.

# lsattr filename
----i-------- filename

If the immutable flag is set, there will be an i in the listing.

The chattr command is used by system administrators to restrict the users from changing a file in a particular way or even the administrator can by mistake delete a critical file because of a mis-typed command. But if the immutable flag is set, these mistakes can be avoided.

chattr can be used to set/unset many more file attributes.

For example, if you want to allow everybody to just append data to a file and not change already entered data, you can set the append bit as follows:

# chattr +a filename

Now the filename can only be opened in append mode for writing data. You can unset the append attribute as follows:

Wow, I'm surprised there is something about *nix I didn't know. You learn something every day. But I probably only didn't know about it because I use reiserfs and xfs. Oh well. I guess I'm save from the kiddies then.

Perhaps someone very smart could write something similar to chattr which demands a password before the change could be made. I'm sure it would involve just a few changes to the kernel file system code and modifying the chattr and lsattr commands ;o)

Perhaps a module for Reiser4 could do it nicely? Something at the file system level which would password protect any files system objects and their attributes.

immutable isn't the only flag you can use, you can set append only, for instance on a log file so that if the service doing the logging gets compromised it can't erase log entries.

the whole thing is much more useful in freebsd and such things as it has security levels, in which nobody, even root, can change these flags. additional steps can be taken to ensure that an administrator must have physical access or authenticate in some other way to change security levels.

on top of that, not all filesystems support these flags, most notably, no version of reiserfs supports them.these attributes also have many more uses, but they don't really make sense most of the time. the things just aren't very useful on linux. other unix based operating systems found better uses for such things, but on linux you'll mostly have to use other means to secure your system.

You wanna make the immutable bit un-changeable? Look up a little tool called 'lcap'. You may wall have to install it, my FC4 boxen don't seem to include it.

Here's a script I used back when to 'lock down' my boxen. It was more of a pain in the ass in the long run and there are other, more manageable methods to achieve similar goals:

#!/bin/bash# Files with i bit set can't be altered - even by root.#chattr -R +i /bin /boot /etc /lib /sbin /usr/bin /usr/include /usr/lib /usr/sbin /root/fw# chattr +a /var/log/mysqld.*.* /var/log/boot*.* /var/log/cron*.* /var/log/messages*.* /var/log/secure*.*## This following will make it so not even root can change the i bits.# Once set - this can not be undone without re-booting!!## You *must* reboot the system from the console to restore# the capability to use chattr to place and remove a or i bits.#lcap CAP_LINUX_IMMUTABLE## The following will prevent raw I/O access to change a or i bits, but# will break a few things - not suggested.## lcap CAP_SYS_RAWIO#echo "Done - system lock down complete"

Some background:http://lists.debian.org/debian-security/2003/03/msg00283.htmlhttp://shearer.org/en/tipsandcomments/capabilities.html

If you use that 2nd lcap line - it will prevent raw I/O operations from changing the a or i bits. But, it'll also make such things - like X - inoperable.

You do realize, root can about blow away the whole filesystem with a simple dd if=/dev/zero of=/de.../hda1, for instance, or by mucking with the partition tables.

Sure, chattr can save an important file from a typo and has marginal uses for restricting non-roots from erasing certain things, even if they own them, but if you know about chattr, there are much simpler methods of avoiding the accidental deletion, and chattr is generally more annoying than useful.

As a security measure, I call it, a false sense of security.

At least until you set securelevel to 2, disable all changing of the flags, mounting/unmounting filesystems, or opening system devices for write access, while in multiuser mode

If you want to stop someone from shutting the immutable flag off after being set you can download the LCAP package. LCAP lets you change kernel options and makes it very easy for you to shut off immutable. This will stop anyone from being able to set the immutable flag at all. However, anything set will remain set. Once you turn off immutable it can't be turned back on until you reboot. So I suggest creating a script and setting it load on any runlevel with networking support enabled. Now any files tagged immutable can't be deleted by anything anymore! I would also set the immutable tag on the script as well so a user can't modify it unless they're in single user mode. I would also suggest turning the append only flag on for your log files. Then turning off the kernel option for append-only as well. This way your logs can have data added to them but they can't be modified. This makes it impossible for an attacker to remove their tracks. Check out Hardening Linux. This trick and others are available in it. This gives you a system similar to BSD secure levels (just not as good).

People are right here, it only prevents accidental deletion. But it also stops some well-known vpn client used at unis and larger companies to overwrite profiles and thus allows to store passwords in those files. To be safe, just mount an encrypted partition, so you only have to enter the password once