[please cc: me on replies]
Hi everyone,
I'm currently rewriting the section of the Securing Debian manual
concerned with the extended attributes of ext2/ext3. Before sending the
patch to Javier Fernández-Sanguino Peña I thought it may be worth asking
for comments here. It's far from being perfect, so if you have a few
minutes and want to have a look, any feedback is welcome -- technical or
grammatical, anything.
Thanks in advance !
Frédéric
<sect1 id="ext-attr">The ext2 file system extended attributes (chattr/lsattr)
<!-- section last edited by Frédéric Schütz <[EMAIL PROTECTED]> -->
<p>
In addition to the usual Unix permissions, the ext2 and ext3
filesystems offer a set of extended attributes that give you more
control over the files on your system. Unlike the basic permissions,
these attribute 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 extended attributes will usually not be saved when you backup
your system, so if you change any of these attributes, 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 the extended attributes available, the two that are most
important for increasing security are referenced by the letters 'a'
and 'i', and they can only be set (or removed) by the superuser:
<list>
<item>The 'a' attribute ('append'): a file with this attribute can only be
opened for writing in append mode, which 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.
<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.
</list>
<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 !
<p>
An easy (but very insecure !) way to improve this situation would be
to remove the <prgn>chattr</prgn> and <prgn>lsattr</prgn> programs
from the system after setting the attributes on files you want to
protect<footnote>Note that you can not simply remove the package
<package>e2fsprogs</package> because it is of priority
<em>Required</em>. You can however safely delete the two binary files
as long as you have a copy on a removable media along with their MD5
fingerprints.</footnote>. This would give you some more time to detect
the intrusion, since the intruder would have to download (and maybe
compile) his own copy of the binaries on your system, but it still
falls short of a secure solution.
<p> A better solution is to use the capabilities, as described in <ref
id="proactive">. The capability of interest 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> 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 extended 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 !
