Re: R/O protection for lower level dirs

On Mon, Apr 01, 2024 at 07:06:14PM +0300, Vitaly Chikunov wrote:
> Hi, 

Hi Vitaly,

> 
> I want to ensure that some deeper directory is write protected (as a non
> security measure but so that some post-install processing do not
> accidentally touch installed files).  Is there a way to achieve this
> with Landlock?

Landlock follows a deny-by-default policy, which is a good practice for
access control.  In your example, you'll need to identify the set of
file hierarchies that should be legitimately allowed, and set the
appropriate access rights on them, not the other way around.

> 
> For example, if we do R/W access to / (root tree is already protected
> enough with DAC) and then R/O access to /home we still get full R/W access
> everywhere and /home seems not restricted. Also, Landlock does not warn for
> such configuration, silently accepting it as valid.
> 
> Practical example:
> 
>   ~$ LL_FS_RW=/ LL_FS_RO=/home sandboxer touch a
>   Executing the sandboxed command...
>   ~$ ls -l a
>   -rw-r--r-- 1 vt vt 0 Apr  1 15:53 a

Because there may have several ways to reach a file (e.g. hard links,
bind mounts), it would be difficult to get, remember, and track all the
related parent file hierarchies.

Landlock ties (ephemeral) permissions to inodes, which means that one
inode with enough rights in the file hierarchy is enough to grant access
for such rights to the files beneath it.  This is checked when accessing
a file, which makes security policies light and flexible (e.g. handles
file renaming, linking, and bind mounting).

In your example, / grants read-write access to all files beneath it, and
/home grants read access to all files beneath it.  When user space
request to write to /home/foo, / grants write permission.

This configuration is then valid, and it makes sure that the security
policy doesn't break user space because of unknown directories nesting
(e.g. setting different access rights on $HOME and $TMPDIR, for which
developers don't have a way to know which one is beneath the other).

For your use case, you'd need to have different file hierarchies and tie
them with specific permissions.  For instance, you could have /usr,
/var/tmp/pkg/postinst, /tmp, /etc .  Keep in mind that you can also
create nested sandboxes or run different stages of the package
installation in dedicated sandboxes (e.g. one for the install step with
access to /usr in read-write, another for the post installation with
access to /var/tmp/pkg/postinst in read-write and /usr in read).

Nicolas is working on a complementary way that would ease sandboxing for
some use cases: https://github.com/landlock-lsm/linux/issues/28
This will help users to quickly sandbox their application instances but
application developers should already be able to implement a more secure
deny-by-default policy without this feature.

> 
> Thanks,
>