Linux-Security-Module Archive mirror
 help / color / mirror / Atom feed

From: Bagas Sanjaya <bagasdotme@gmail.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Security Module Subsystem
	<linux-security-module@vger.kernel.org>
Cc: "Kees Cook" <keescook@chromium.org>,
	"Andy Lutomirski" <luto@amacapital.net>,
	"Will Drewry" <wad@chromium.org>,
	"Mickaël Salaün" <mic@digikod.net>,
	"Theodore Ts'o" <tytso@mit.edu>,
	"Alan Stern" <stern@rowland.harvard.edu>,
	"Ali Polatel" <alip@chesswob.org>
Subject: TOCTOU-free exec(), chdir(), open() with O_PATH sandbox emulation support?
Date: Thu, 22 Feb 2024 13:41:57 +0700	[thread overview]
Message-ID: <ZdbstX5p4M_-RjXC@archie.me> (raw)

[-- Attachment #1: Type: text/plain, Size: 2216 bytes --]

Hi,

Ali Polatel <alip@chesswob.org> opened feature request bug on Bugzilla
regarding TOCTOU-free sandbox emulation support [1]. He wrote:

> Thanks to the addition of seccomp_addfd, now it is possible to emulate a vast number of system calls to achieve a TOCTOU-free sandbox in userspace. There're however three exceptions to this:
> 1. exec family calls cannot be emulated so a sandbox disallowing exec calls has no choice but to continue the exec call in sandbox process allowing TOCTOU.
> 2. chdir family calls cannot be emulated so a sandbox disallowing chdir calls to hide paths has no choice but to continue the chdir call in sandbox process allowing TOCTOU.
> 3. open calls with the O_PATH flag cannot be emulated (addfd returns EBADF on o_path fds) again a sandbox disallowing open calls with O_PATH flag to hide paths has no choice but to continue the open call in sandbox process allowing TOCTOU.
> 
> It'd be awesome for the kernel to provide TOCTOU-free ways to sandbox these three cases.
> 
> For a bit of context, I am the author of syd, a seccomp and landlock based application sandbox with support for namespaces, you can read here about why this feature request is relevant and more: http://man.exherbolinux.org/syd.7.html
> 
> To quote the relevant bit from the manual page:
>> BUGS
>> 
>> In the operation of syd, certain system calls are not fully emulated due to seccomp(2) limitations, resulting in the sandbox process continuing these calls directly. These include execve(2), execveat(2) for execution, chdir(2), fchdir(2) for directory changes, and open(2) operations with O_PATH flag. Consequently, this behavior exposes vulnerabilities to time-of-check to time-of-use attacks, allowing for the circumvention of Exec Sandboxing to execute denylisted paths, the bypass of Stat Sandboxing for unauthorized directory access without disclosing directory contents (owing to getdents(2) call emulation), and the detection of hidden files without revealing file metadata, as stat(2) calls are emulated.

Is the feature request viable/realistic?

Thanks.

[1]: https://bugzilla.kernel.org/show_bug.cgi?id=218501

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

                 reply	other threads:[~2024-02-22  6:42 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=ZdbstX5p4M_-RjXC@archie.me \
    --to=bagasdotme@gmail.com \
    --cc=alip@chesswob.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mic@digikod.net \
    --cc=stern@rowland.harvard.edu \
    --cc=tytso@mit.edu \
    --cc=wad@chromium.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

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).