Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#30068 - [mlocate] updatedb.conf should ignore encrypted file systems

Attached to Project: Arch Linux
Opened by Xyne (Xyne) - Tuesday, 29 May 2012, 22:05 GMT
Last edited by Allan McRae (Allan) - Tuesday, 19 June 2012, 15:28 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Allan McRae (Allan)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

/etc/updatedb.conf lists file systems that should be ignored with PRUNEFS. The current default ignores ephemeral file systems (e.g. tmpfs) and network file systems (e.g. cifs).

By default, it should also ignore encrypted file systems. By not ignoring encrypted file systems, the unencrypted names and locations of encrypted files (when mounted) are stored in the mlocate database, which may expose secret/private data to an attacker and will at the very least provide evidence of their existence.

Please add at least the following to the default PRUNEFS array in updatedb.conf:
ecryptfs fuse.encfs

The first is for eCryptfs and the second is for EncFS. Both are widely used and available in [community]. eCryptfs is also officially supported upstream in the kernel.

Thanks.
This task depends upon

Closed by  Allan McRae (Allan)
Tuesday, 19 June 2012, 15:28 GMT
Reason for closing:  Implemented
Additional comments about closing:  mlocate-0.25-2
Comment by Jan de Groot (JGC) - Tuesday, 29 May 2012, 23:56 GMT
The problem with this is that encfs and ecryptfs are not the only encrypted filesystems. What if you made an encrypted blockdevice using dm-crypt and have a regular ext4 filesystem on top of that? There's no sane way to detect all use cases for this.
Comment by Xyne (Xyne) - Wednesday, 30 May 2012, 00:43 GMT
I should have been clearer above about what I meant by "encrypted file systems". I mean the actual file system, not files themselves.

When an encrypted block device is decrypted and mounted, the encryption is transparent to the system. The block device behaves as though it were a regular partition as far as mounting goes, and the system only sees a generic file system (e.g. ext4). There is no way to detect that via the file system type.


eCryptfs and EncFS are stacked file systems. The system itself reports their file systems as encrypted (ecryptfs, fuse.encfs). This is different from encrypted block device. There is no need for "detection". The type is given in mtab and elsewhere.

There may be other encrypted file systems, but these two are the most common and most widely supported (as mentioned, eCryptfs is supported upstream in the kernel), so it makes sense to include them. If other systems become more popular then they can be added too. Given how obscure some of the current defaults are, this should not be an issue.

Comment by Allan McRae (Allan) - Wednesday, 30 May 2012, 01:05 GMT
Hmm... I think the current defaults are all for filesystems that get removed.
Comment by Xyne (Xyne) - Wednesday, 30 May 2012, 17:57 GMT
They are. That's the point. When you mount an encrypted file system, the plaintext names are visible in the mountpoint. If updatedb runs when the file system is mounted, then all of the plaintext names will be stored in the database. That means that even when the file system is unmounted, someone can still get the list of files from the database. Even if the database is deleted, those names will have been written to the disk in an unencrypted form. It is a serious security leak for an encryption scheme.

By adding ecryptfs and fuse.encfs to the PRUNEFS list, updatedb will *not* stores the plaintext names of the encrypted files.

You could argue that users should be aware of this and edit the list themselves, but it isn't obvious and there is no reason not to choose a secure setup by default. The file itself is added by the packager, so there is no issue of modifying upstream defaults either.


edit: typos
Comment by Xyne (Xyne) - Wednesday, 30 May 2012, 18:10 GMT
Ok, I just reread your comment and realized that I had misinterpreted it. You meant removed in the sense of unmounted, as in those files disappear eventually.

I don't really agree. Network file shares can be expected to be persistent in many cases, and the files located on them will often remain unchanged. The same applies to external devices. tmpfs is also usually mounted for extended periods of time and non-volatile for much of the session. Encrypted file systems are usually used the same way as tmpfs, i.e. mounted when needed, often for the duration of the session, but with the expectation that they will be unmounted at some point.

In any case, encrypted file systems are clearly in their own category and I think they should be included with the defaults.

Loading...