Review (2): sect. 4.16.2 of the Securing Debian manual

[Frederic Schutz <schutz@mathgen.ch>]

Thanks to comments from Alexander Reelsen, Adam Endrodi and Peter Cordes,
I made some more changes to the section on the ext2fs attributes. As Adam
pointed out, the term "extended attributes" seems to refer to ACLs (which
are also missing from the manual), so I renamed the section "ext2fs
specific attributes". I also removed the paragraph that was suggesting a
"security by obscurity" method -- even with the caveats, it wasn't a good
idea to put that here (it still says something about the method, but only
because it was mentioned in previous versions of the manual, and just to
mention that it is a very bad idea).

Also, I've been happy to see that what I wrote seems more or less
technically sound, but the people who read the text and commented on it
needed some more explanations -- this makes me think that there is still
plenty of room for improvment in my writing style :-( again, any comment
welcome !

I kept some of the comments for the future section on capabilities, thanks
to those who made them.

Here is the new version, just in case someone wants to have another look.

Frédéric

<sect1 id="ext2attr">The ext2 filesystem specific attributes (chattr/lsattr)
<!-- section last edited by Frédéric Schütz <schutz@mathgen.ch> -->

<p>
In addition to the usual Unix permissions, the ext2 and ext3
filesystems offer a set of specific attributes that give you more control
over the files on your system. Unlike the basic permissions, these
attributes are not displayed by the usual <prgn>ls -l</prgn> command or
changed using <prgn>chmod</prgn>, and you need two other utilities,
<prgn>lsattr</prgn> and <prgn>chattr</prgn> (in package
<package>e2fsprogs</package>) to manage them. Note that this means that
these attributes will usually not be saved when you backup your system, so
if you change any of them, it may be worth saving the successive
<prgn>chattr</prgn> commands in a script so that you can set them again
later if you have to restore a backup.

<p>
Among all available attributes, the two that are most important for
increasing security are referenced by the letters 'i' and 'a', and they
can only be set (or removed) by the superuser:

<list>
<item>The 'i' attribute ('immutable'): a file with this attribute can
neither be modified nor deleted or renamed and no link can be created
to it, even by the superuser.

<item>The 'a' attribute ('append'): this attribute has the same effect
that the immutable attribute, except that you can still open the file in
append mode. This means that you can still add more content to it but it
is impossible to modify previous content. This attribute is especially
useful for the log files stored in <file>/var/log/</file>, though you
should consider that they get moved sometimes due to the log rotation
scripts.
</list>

<p>
These attributes can also be set for directories, in which case everyone
is denied the right to modify the contents of a directory list (eg. rename
or remove a file, ...). When applied to a directory, the append attribute
only allows file creation.

<p>
It is easy to see how the 'a' attribute improves security, by giving
to programs that are not running as the superuser the ability to add
data to a file without modifying its previous content. On the other
hand, the 'i' attribute seems less interesting: after all, the
superuser can already use the basic Unix permissions to restrict
access to a file, and an intruder that would get access to the
superuser account could always use the <prgn>chattr</prgn> program to
remove the attribute. Such an intruder may first be confused when he
sees that he is not able to remove a file, but you should not assume
that he is blind - after all, he got into your system ! Some manuals
(including a previous version of this document) suggest to simply
remove the <prgn>chattr</prgn> and <prgn>lsattr</prgn> programs from
the system to increase security, but this kind of strategy, also known as
"security by obscurity", is to be absolutely avoided, since it
provides a false sense of security.

<p>
A secure way to solve this problem is to use the capabilities of the Linux
kernel, as described in <ref id="proactive">. The capability of
interest here is called <tt>CAP_LINUX_IMMUTABLE</tt>: if you remove it
from the capabilities bounding set (using for example the command
<tt>lcap CAP_LINUX_IMMUTABLE</tt>) it won't be possible to change any
'a' or 'i' attribute on your system anymore, even by the superuser ! A
complete strategy could be as follows:

<enumlist>
  <item> Set the attributes 'a' and 'i' on any file you want;
  <item> Add the command <tt>lcap CAP_LINUX_IMMUTABLE</tt> (as well as
         <tt>lcap CAP_SYS_MODULE</tt>, as suggested in <ref id="proactive">)
         to one of the startup scripts;
  <item> Set the 'i' attribute on this script and other startup files, as
         well as on the <prgn>lcap</prgn> binary itself;
  <item> Execute the above command manually (or reboot your system to
         make sure everything works as planned).
</enumlist>

<p>
Now that the capability has been removed from the system, an intruder
can not change any attribute on the protected files, and thus can not
change or remove the files. If he forces the machine to reboot (which is
the only way to restore the capabilities bounding set), it will easily be
detected, and the capability will be removed again as soon as the system
restarts anyway. The only way to change a protected file would be to boot
the system in single-user mode or using another bootdisk, two operations
that require physical access to the machine !