Re: R/O protection for lower level dirs

Mickaël,

On Tue, Apr 02, 2024 at 11:11:39AM +0200, Mickaël Salaün wrote:
> On Mon, Apr 01, 2024 at 07:06:14PM +0300, Vitaly Chikunov wrote:
> > 
> > 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 for the answer.

Looks like it's currently impossible to create more restricted hierarchy
inside of less restricted. I think this isn't consequence of 'deny by
default' approach but sort of additivity of allowed permissions.
Positive permissions of wider hierarchy will be added to more
restrictive sub-hierarchy and supersede them.

To add more detail, what I tried to achieve: rpmbuild installs into so
called 'buildroot', which is (for ALT) '/usr/src/tmp/name-buildroot'
directory inside of '/usr/src/tmp' TMPDIR (and '/usr/src' is a HONE). When
%check section is performed some scripts may inadvertently modify
buildroot content which I thought to block. But because TMPDIR should be
unrestricted (and / and HOME are not need to be restricted) it is not
possible by any means to restrict buildroot.

It is not possible, for example, to permit R/W to all existing entities
of TMPDIR excluding 'name-buildroot', because in that case TMPDIR itself
should have R/O permissions (it's needed to not supersede
name-buildroot) and this will defy TMPDIR purpose.

That work of Nicolas looks promising for the goal I wanted to achieve
and overall Landlock flexibility.

Thanks,


> 
> > 
> > Thanks,
> >