Proposal for the new mount options: no_symlink and no_new_symlink

Proposal for the new mount options: no_symlink and no_new_symlink

[Igor Zhbanov]

Hello,

I want to implement 2 new mount options: "no_symlink" and "no_new_symlink".
The "nosymlink" option will act like "nodev", i.e. it will ignore all created
symbolic links.

And the option "no_new_symlink" is for more relaxed configuration. It will
allow to follow already existing symbolic links but forbid to create new.
It could be useful to remount filesystem after system upgrade with this option.

The idea behind these options is that a user controlled symbolic link could
affect poorly designed applications or system services that are using fixed
paths to read/write their data. Such a place could be: /tmp (or similar)
directory, unknown USB drive with ext4 or user home.

I.e. it would be possible to mount external storage with hardened
"-o nosuid,nodev,no_symlink" to be sure that it contain only regular files.

What do you think about this?
The patch-set is simple. But I would like to know your opinion first.

Thank you.

Re: Proposal for the new mount options: no_symlink and no_new_symlink

[Aleksa Sarai]

[-- Attachment #1: Type: text/plain, Size: 1115 bytes --]

On 2020-11-13, Igor Zhbanov <izh1979@gmail.com> wrote:
> I want to implement 2 new mount options: "no_symlink" and "no_new_symlink".
> The "nosymlink" option will act like "nodev", i.e. it will ignore all created
> symbolic links.

nosymlink has already been implemented (though the name "nosymfollow"
was used to match that corresponding FreeBSD mount option) by Ross
Zwisler and is in Al's tree[1].

> And the option "no_new_symlink" is for more relaxed configuration. It will
> allow to follow already existing symbolic links but forbid to create new.
> It could be useful to remount filesystem after system upgrade with this option.

This seems less generally useful than nosymfollow and it doesn't really
match any other inode-type-blocking mount options. You could also
implement this using existing facilities (seccomp and AppArmor), so I'm
not sure much is gained by making this a separate mount option.

[1]: https://lkml.kernel.org/lkml/20200827201015.GC1236603@ZenIV.linux.org.uk/

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]