linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Günther Noack" <gnoack@google.com>
To: linux-security-module@vger.kernel.org,
	"Mickaël Salaün" <mic@digikod.net>
Cc: Jeff Xu <jeffxu@google.com>,
	Jorge Lucangeli Obes <jorgelo@chromium.org>,
	Allen Webb <allenwebb@google.com>,
	Dmitry Torokhov <dtor@google.com>,
	Paul Moore <paul@paul-moore.com>,
	Konstantin Meskhidze <konstantin.meskhidze@huawei.com>,
	linux-fsdevel@vger.kernel.org, Kees Cook <keescook@chromium.org>,
	Jiri Slaby <jirislaby@kernel.org>,
	Simon Brand <simon.brand@postadigitale.de>,
	linux-hardening@vger.kernel.org
Subject: Re: [PATCH v2 0/6] Landlock: ioctl support
Date: Fri, 23 Jun 2023 17:20:27 +0200	[thread overview]
Message-ID: <ZJW4O+HVymf4nB6A@google.com> (raw)
In-Reply-To: <20230623144329.136541-1-gnoack@google.com>

Hello!

On Fri, Jun 23, 2023 at 04:43:23PM +0200, Günther Noack wrote:
> Proposed approach
> ~~~~~~~~~~~~~~~~~
> 
> Introduce the LANDLOCK_ACCESS_FS_IOCTL right, which restricts the use
> of ioctl(2) on file descriptors.
> 
> We attach the LANDLOCK_ACCESS_FS_IOCTL right to opened file
> descriptors, as we already do for LANDLOCK_ACCESS_FS_TRUNCATE.
> 
> I believe that this approach works for the majority of use cases, and
> offers a good trade-off between Landlock API and implementation
> complexity and flexibility when the feature is used.
> 
> Current limitations
> ~~~~~~~~~~~~~~~~~~~
> 
> With this patch set, ioctl(2) requests can *not* be filtered based on
> file type, device number (dev_t) or on the ioctl(2) request number.
> 
> On the initial RFC patch set [1], we have reached consensus to start
> with this simpler coarse-grained approach, and build additional ioctl
> restriction capabilities on top in subsequent steps.

We *could* use this opportunity to blanket disable the TIOCSTI ioctl, if a
Landlock policy gets enabled and ioctls are handled.

TIOCSTI is a TTY ioctl which is commonly used as a sandbox escape, if the
sandboxes system can get a hold on a TTY file descriptor from outside the
sandbox (like STDOUT, hah).

An excellent summary of these problems was already written by Kees Cook on the
Linux patch which removes TIOCSTI depending on a kernel config option:
https://lore.kernel.org/lkml/20221022182828.give.717-kees@kernel.org/

Unfortunately on the distributions I have tested so far (Debian and Arch Linux),
TIOCSTI is still enabled.

***Proposal***:

  I am in favor of *disabling* TIOCSTI in all Landlocked processes,
  if the Landlock policy handles the LANDLOCK_ACCESS_FS_IOCTL right.

If we want to do it in a backwards-compatible way, now would be the time to add
it to the patch set. :)

As far as I can tell, there are no good legitimate use cases for TIOCSTI, and it
would fix the aforementioned sandbox escaping trick for a Landlocked process.
With the patch set as it is now, the only way to prevent that sandbox escape is
unfortunately to either (1) close the TTY file descriptors when enabling
Landlock, or (2) rely on an outside process to pass something else than a TTY
for FDs 0, 1 and 2.

Does that sound reasonable?  If yes, I'd send an update to this patch set which
forbids TIOCSTI.

Thanks,
—Günther

-- 
Sent using Mutt 🐕 Woof Woof

  parent reply	other threads:[~2023-06-23 15:20 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-23 14:43 [PATCH v2 0/6] Landlock: ioctl support Günther Noack
2023-06-23 14:43 ` [PATCH v2 1/6] landlock: Increment Landlock ABI version to 4 Günther Noack
2023-07-12 10:55   ` Mickaël Salaün
2023-06-23 14:43 ` [PATCH v2 2/6] landlock: Add LANDLOCK_ACCESS_FS_IOCTL access right Günther Noack
2023-06-23 14:43 ` [PATCH v2 3/6] selftests/landlock: Test ioctl support Günther Noack
2023-06-23 14:43 ` [PATCH v2 4/6] selftests/landlock: Test ioctl with memfds Günther Noack
2023-07-12 10:55   ` Mickaël Salaün
2023-06-23 14:43 ` [PATCH v2 5/6] samples/landlock: Add support for LANDLOCK_ACCESS_FS_IOCTL Günther Noack
2023-06-23 14:43 ` [PATCH v2 6/6] landlock: Document ioctl support Günther Noack
2023-06-23 15:20 ` Günther Noack [this message]
2023-06-23 16:37   ` [PATCH v2 0/6] Landlock: " Mickaël Salaün
2023-06-26 18:13     ` Günther Noack
2023-07-12 10:55 ` Mickaël Salaün
2023-07-12 14:56   ` Günther Noack
2023-07-12 17:48     ` Mickaël Salaün
2023-07-13 22:38       ` Günther Noack
2023-07-24 19:03         ` Mickaël Salaün
2023-07-27  9:32           ` Günther Noack
2023-07-28 13:52             ` Mickaël Salaün
2023-07-31  8:31               ` Günther Noack

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=ZJW4O+HVymf4nB6A@google.com \
    --to=gnoack@google.com \
    --cc=allenwebb@google.com \
    --cc=dtor@google.com \
    --cc=jeffxu@google.com \
    --cc=jirislaby@kernel.org \
    --cc=jorgelo@chromium.org \
    --cc=keescook@chromium.org \
    --cc=konstantin.meskhidze@huawei.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mic@digikod.net \
    --cc=paul@paul-moore.com \
    --cc=simon.brand@postadigitale.de \
    /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 NNTP newsgroup(s).