On 22/12/2016 01:57, Al Viro wrote: > On Thu, Dec 22, 2016 at 01:01:39AM +0100, Mickaël Salaün wrote: > >> SELinux should be interested. This is useful to create sandboxes so >> other LSM may be interested too >> >> I'm working on a new LSM and I would like this kind of hook to create a >> real read-only environment. > > What the...? Have you noticed > if (!sb_start_write_trylock(inode->i_sb)) > return; > > if (__mnt_want_write(mnt) != 0) > goto skip_update; > in touch_atime()? Just mount them read-only in your sandbox (on either > level - both per-mountpoint and per-fs r/o will do) and be done > with that; why bother with LSM when regular tools would suffice? > Of course a read-only mount point can do the trick (except for anonymous inodes). However, a security policy (e.g. for SELinux) should not (and can't always) rely on mount options. For example, a security policy can come from a distro but they may not want to tie mount options with this policy. We may also not want a sandbox to being able to change mount options (even with user namespaces). Being able to write (meta-)data, whereas a security policy said that it's not allowed, seems like a flaw in this policy. Moreover, modifying access time is an easy way to create cover-channels without any LSM being able to notice it.
Attachment:
signature.asc
Description: OpenPGP digital signature
