From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from vmicros1.altlinux.org (vmicros1.altlinux.org [194.107.17.57]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5326314A0A6 for ; Wed, 3 Apr 2024 15:20:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=194.107.17.57 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712157654; cv=none; b=Lx9xZcgODI7igmnGds3CG4VUXGxWKcqKDNvtjoDK9qt0FEIytUVga5WFYzgcyZfzzewiuKjPVbLQF2M+mzpZYza77BsU78dXuriTMoFViEZQfAV1D3WQFHZUosZCz5vIupos0gsfh2txTTwYzfK5/+eUt17iw2MF+kkvMmzzt+g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712157654; c=relaxed/simple; bh=wRRRat2WzvMAFRJEfRWyrArP7RXy7I9TOuJuqJ64XHU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=k/4A/Rbisc6Bhc+DD2wAkYe2gpTrA4krmFkRkSthlzwATJTGzSIRr/svrEzth0jjt9MKjBE+GWtbkdBfvHCX+XbeFP6gsFQSC3596Paa0orpYWud0GfBFAP42EKbgwYu08L7XsrNURfgEDKvKpRLdu7BREpZEeI4GQv4ofPnWhY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=altlinux.org; spf=pass smtp.mailfrom=altlinux.org; arc=none smtp.client-ip=194.107.17.57 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=altlinux.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=altlinux.org Received: from imap.altlinux.org (imap.altlinux.org [194.107.17.38]) by vmicros1.altlinux.org (Postfix) with ESMTP id 9C21F72C8CC; Wed, 3 Apr 2024 18:20:43 +0300 (MSK) Received: from altlinux.org (sole.flsd.net [185.75.180.6]) by imap.altlinux.org (Postfix) with ESMTPSA id 8E9E136D0160; Wed, 3 Apr 2024 18:20:43 +0300 (MSK) Date: Wed, 3 Apr 2024 18:20:43 +0300 From: Vitaly Chikunov To: =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= Cc: landlock@lists.linux.dev Subject: Re: R/O protection for lower level dirs Message-ID: <20240403152043.fc5gpqu2ghlahyyj@altlinux.org> References: <20240401160614.32py2wrijdp5yots@altlinux.org> <20240402.quaQuieyohd9@digikod.net> Precedence: bulk X-Mailing-List: landlock@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240402.quaQuieyohd9@digikod.net> 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, > >