From: "Mickaël Salaün" <mic@digikod.net>
To: Vitaly Chikunov <vt@altlinux.org>
Cc: landlock@lists.linux.dev
Subject: Re: R/O protection for lower level dirs
Date: Wed, 3 Apr 2024 18:57:06 +0200 [thread overview]
Message-ID: <20240403.Taip4yae2ohn@digikod.net> (raw)
In-Reply-To: <20240403152043.fc5gpqu2ghlahyyj@altlinux.org>
On Wed, Apr 03, 2024 at 06:20:43PM +0300, Vitaly Chikunov wrote:
> 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.
Correct for the same ruleset.
All rules in the same ruleset are ORed whatever their file hierarchy,
but nested sandboxes (i.e. sequential calls to landlock_restrict_self())
can only add more restrictions in relation to their parent sandboxes.
>
> 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.
The issue is that tmp is nested in src (and of course everything is
nested in /). What about using different file hierarchies like this:
* /usr/pkg/src
* /usr/pkg/tmp
* /usr/pkg/root (which would be a bind mount of /, if this is really
needed)
I'm wondering why buildroot needs access to / though. Could we identify
which resources it really needs?
>
> 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.
What about creating dedicated directories beneath TMPDIR?
>
> That work of Nicolas looks promising for the goal I wanted to achieve
> and overall Landlock flexibility.
>
> Thanks,
>
>
> >
> > >
> > > Thanks,
> > >
>
next prev parent reply other threads:[~2024-04-03 16:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-01 16:06 R/O protection for lower level dirs Vitaly Chikunov
2024-04-02 9:11 ` Mickaël Salaün
2024-04-03 15:20 ` Vitaly Chikunov
2024-04-03 16:57 ` Mickaël Salaün [this message]
2024-04-05 16:04 ` Vitaly Chikunov
2024-04-06 17:19 ` Mickaël Salaün
2024-04-04 8:03 ` Simon de Vlieger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240403.Taip4yae2ohn@digikod.net \
--to=mic@digikod.net \
--cc=landlock@lists.linux.dev \
--cc=vt@altlinux.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).