Following on from my article on Linux
Capabilities I thought I would cover another, interesting, but yet not that
well known feature on Linux – that of filesystem attributes. This is not to be
confused with extended ACLs.
Linux (file) attributes cover a wide range of
features, such as the ability to mark a file as immutable, require secure
deletion (read the caveats in the man page), or to exclude it from backups
(aka. no dump). Some are user modifiable (with appropriate permissions), some
are not.
You can view user attributes for a file using lsattr and change them using chattr.
[root@centos-7-2-t1 ~]# echo hello world > a.a
[root@centos-7-2-t1 ~]# lsattr a.a
---------------- a.a
[root@centos-7-2-t1 ~]# chattr +i a.a
[root@centos-7-2-t1 ~]# lsattr a.a
----i----------- a.a
The man page chattr(1) gives you an idea of some of the features; to
quote:
The letters 'aAcCdDeijsStTu'
select the new attributes for the files:
append only (a), no atime
updates (A), compressed (c), no copy on write
(C), no dump (d),
synchronous directory updates (D), extent format (e),
immutable (i),
data journalling (j), secure deletion (s), synchronous
updates (S), no tail-merging
(t), top of directory hierarchy
(T), and
undeletable (u).
Of particular interest from a security
point-of-view are the append-only and immutable attributes. These prevent
changes, even by root, to such files. This includes renaming and changing
permissions.
The exceptions are changing the
append-only/immutable attributes (if you are privileged) and appending to an
append-only file. For example, following on from the a.a file change above to being
immutable, if we try to alter it as root we get the following:
[root@centos-7-2-t1 ~]# rm -f a.a
rm: cannot remove ‘a.a’: Operation not permitted
[root@centos-7-2-t1 ~]# unlink a.a
unlink: cannot unlink ‘a.a’: Operation not permitted
[root@centos-7-2-t1 ~]# chmod 777 a.a
chmod: changing permissions of ‘a.a’: Operation not permitted
[root@centos-7-2-t1 ~]# mv a.a b.b
mv: cannot move ‘a.a’ to ‘b.b’: Operation not permitted
[root@centos-7-2-t1 ~]# echo more >> a.a
-bash: a.a: Permission denied
[root@centos-7-2-t1 ~]# ls -l a.a
-rw-r--r--. 1 root root 12 Jun 23 12:34 a.a
So the file looks normal from an ls, but even root cannot appear
to do anything. An unsuspecting sysadmin or adversary is going to be at best
confused by such a thing.
OK; you could (attempt to) update the raw
device, for example ;-), but isn't this all about raising the bar.
We can always, as root, clear the attribute
then delete:
[root@centos-7-2-t1 ~]# chattr -i a.a
[root@centos-7-2-t1 ~]# rm a.a
rm: remove regular file ‘a.a’? y
[root@centos-7-2-t1 ~]#
Does this infer there are limited benefits, in
that this only protects files by non-root users? Well, not exactly.
First, as root, as an additional step you need
to remove the attribute or change it (eg from immutable to append-only). You
need to be in a situation that a) you can do this (an exploit may not initially
give you that ability) and b) you know it needs to be done (awareness).
[root@centos-7-2-t1 ~]# lsattr a.a
----i----------- a.a
[root@centos-7-2-t1 ~]# chattr =a a.a
[root@centos-7-2-t1 ~]# lsattr a.a
-----a---------- a.a
Secondly, when we combine this with Linux
Capabilities, we can have powerful 'root-like' accounts that cannot change the
attribute – because you need the CAP_LINUX_IMMUTABLE capability to do this; a
normal user cannot set/clear this flag – even on files they own.
As for root itself, we can always use setpriv or something else to spawn a
(root) program with CAP_LINUX_IMMUTABLE removed from the bounding and
inheritable set.
This doesn't prevent privilege escalation in
various circumstances with these 'root-like' accounts. For example, if you have
CAP_DAC_OVERRIDE you could change /etc/shadow and then become root; but it
makes compromise noisier and thus more likely to be detected.
I hope you find this useful.
