Frustrating Sysadmins, pentesters and adversaries with Linux Attributes

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.