Re: Immutable flag and packages
> 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
Reply to: