Re: Immutable flag and packages

[bear@coyotesong.com]

> It would be
> extremely annoying to have to remove the immutable attribute every
> time I wanted to make a change somewhere in the filesystem.

Just to be clear, the immutable flag is an extended attribute of
a *file*, not an entire filesystem.  A single directory can have a
mix of mutable and immutable files and subdirectories.  (An immutable
subdirectory, as I recall, can still have mutable files.)

As a trivial example, it would be reasonable to have /etc/fstab
marked immutable, while /etc/mtab would be mutable.  Another example
would be an immutable /etc/passwd and mutable /etc/shadow, to allow
users to change their passwords but not their gecos field.

>    1. "installation" should set the immutable flag for any
>       binary files and possiibly some configuration files.
>       Likewise, removing or updating a package will need to 
>       clear that flag.
> 
> I don't see this as a good idea, myself.  If the superuser wants to
> modify/remove a file, why should we stand in his way?

Why bother with packages at all, then?  Let's just ship 'em tarballs! :-)

Seriously, here are two reasons for having this as the default 
behavior:

1. Packaged files, by definition, are part of a package.  It doesn't
   seem unreasonable to me to say, in essence, that changing part of
   a package will require an explicit action by the superuser, either
   removing the entire package (via dpkg) or an explicit "chattr -i". 

   Here's a rough analogy I thought of this morning.  Setting the
   immutable bit is a lot like the safety on a gun.  It doesn't prevent
   you from using it, it just makes *you* a bit safer because of the
   conscious thought that occurs as you flip off the safety.  ("Is this
   situation so serious that deadly force is necessary?")  

   In the same way, clearing the immutable bit should make you ask
   if your action is really necessary.  The immutable bit would not be 
   set on *all* files, only those files that really shouldn't be modified
   except through a program manager.  After all, do you *really* want
   to modify /bin/bash?

2. It is a simple way to improve security, since many cracker techniques
   can't change the immutable bit before attempting to overwrite a file.
   It won't stop a cracker with a root shell, but it might be enough
   to stop some crackers armed only with a list of SMTP etc. flaws.

   Or, to rephrase your own question, "If the cracker wants to modify/
   remove a file, why should we stand in his way?"  This isn't too much
   an issue today, since my modem isn't up 24/7, but with cable modems
   that will change.

There's one other place where the immutable bit may make sense, although
I'm not sure if it's worth the hassles.  That's in the /etc directory.
If you access files like /etc/passwd, /etc/export, /etc/ttysecure, etc., 
by hand then the immutable bit would be a pain.  On the other hand, you 
could argue that these files *especially* should be protected by that
flag, since that's where a malicious hacker will attack.

Bear Giles
bear@coyotesong.com


--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org