[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <hasMYF5DZHQQe2qNdAWfRbjZZjdV_KPTt4HFQwwUSIwl_73pgEbYIbsU6oN4LzkU6_kS8B9krXHJt63boPcmhesrvy4BN-QyX6dm_3Br_Jk=@hexsys.org>
Date: Tue, 26 Nov 2024 05:23:29 +0000
From: Ali Polatel <alip@...sys.org>
To: oss-security@...ts.openwall.com
Subject: Re: Article: State of Sandboxing in Linux
On Monday, November 25th, 2024 at 17:04, Evan Carroll <me@...ncarroll.com> wrote:
> > You might want "sydbox", though I wouldn't know.
>
>
> Historically, there were 10,000 different ways to sandbox things. From
> chroots, to firejails. I however don't understand why anyone would
> entertain any of these pre-containerization methods today. That's why I'm
> questioning what's the purpose of comparing different sandboxing methods in
> isolation of the current status quo -- containerization. Why would anyone
> want sydbox (whatever it is) over rootless podman?
Your argument makes no sense and makes me believe you're either ignorant
or borderline trolling, however I'll try one last time:
Here is a comprehensive list of technologies that sydbox uses:
1. seccomp-bpf
2. seccomp-unotify
3. landlock
4. namespaces (including user namespaces)
5. ptrace
6. MDWE
Out of the technologies listed above only ptrace is considerably
older to the point you can consider it "pre-containerization".
Again you'd be comparing apples and oranges because sandboxing
has nothing to do with containerization and there's nothing
to stop you from using syd-oci or gVisor as a runtime to podman.
Read on, it gets better.
> By the way, you mention "when would I want [...] over kernel
>
> > user-namespaces", which I think is a complete and utter misunderstanding
> > of the problem domain.
> >
> > sydbox documents that one of the technologies it uses in its source code
> > is user namespaces. Generally, "user namespaces" isn't a program you
> > use, it's a technique you can make use of in the source code of another
> > program entirely... such as sydbox or at a high level, podman.
>
>
> Right! And if it's not providing anything except user namespaces, and
> cgroups, and secgroups, it's just another containerization tool. So why
> introduce a term that has fallen entirely into disuse like "sandbox" that
> includes technologies that predate contianers. As far as I can see, that's
> adding complexity and explaining nothing. And, why not compare these tools
> against the 600 lb gorilla in containerization: rootless podman.
I'll just laugh at this because I am speechless... You seem to be much
more ignorant than I initially believed. Start by going to cve.mitre.org
and search for user namespaces.
> From looking through the sydbox homepage, and very quickly checking for
>
> > keywords such as "podman", I got pointed to this link:
> >
> > https://man.exherbolinux.org/syd-oci.1.html
> >
> > It suggests that the relevance of this software to podman is that you
> > can use "sydbox" as an OCI runtime for podman, to replace "crun" or
> > "runc", via:
> >
> > podman run --runtime=syd-oci
>
>
> So now we're getting at it: syd isn't a "sandboxing" thing at all. It's a
> container runtime. And now the 100 million dollar question is very simple,
> how does this container runtime compare with youki, which is also in rust
> and it clearly says it's based on, from your link "It is largely based on
> youki": Youki has 113 contributors. Sydbox seems to be a one man show
> https://gitlab.exherbo.org/sydbox/sydbox/-/commits/main/?ref_type=HEADS
This is hilarious. syd-oci is a container runtime. sydbox is a general purpose
sandbox that aims to make sandboxing as easy as text searching is with grep.
Please be so kind to RTFM before you actually throw random ideas at me.
I am not your therapist, this page might help tho: http://man.exherbolinux.org
Let me give you a list of features that your container engine does/can/will not do,
so you'll maybe come to the realization that sandboxing is just a different concept
than containerization not a "pre-historic" technology:
1. Setting AT_SECURE auxillary vector to avoid unsafe environment variables.
http://man.exherbolinux.org/syd.7.html#Enforcing_AT_SECURE_and_UID/GID_Verification
Apparmor and iirc SELinux does this too.
2. Enforcing PIE executables and thereby ASLR.
http://man.exherbolinux.org/syd.7.html#Enforcing_Position-Independent_Executables_(PIE)
3. Enforcing non-executable stack (see the ssh-agent exploit where the smart people
dlopen an execstack library to turn the whole stack of a program into executable
and drop shellcode, like in the 90s, no worries all these are prehistoric in your funny bubble,
so please stay in there, SELinux does the same)
http://man.exherbolinux.org/syd.7.html#Enforcing_Non-Executable_Stack
4. Process name change restrictions (especially useful in malware analysis):
http://man.exherbolinux.org/syd.7.html#Process_Name_Modification_Restriction
5. Prevent timing analyses on block or character devices via stat(2) or inotify(7)/fanotify(7)
http://man.exherbolinux.org/syd.7.html#Device_Sidechannel_Mitigations
6. Enhanced Path Integrity measures similar to SafeName LSM: (see the recent unsafe shell expansion thread)
http://man.exherbolinux.org/syd.7.html#Enhanced_Path_Integrity_Measures
7. Preventing NULL arguments for execve(2) argv and envp pointers, thereby
raising the bar for an attacker preparing to exploit via ROP:
(HardenedBSD implemented this short after sydbox)
http://man.exherbolinux.org/syd.7.html#Enhanced_execve_and_execveat_Syscall_Validation
8. Enforcing of non-executable memory file descriptors (which are 777 by default):
(ChromeOS does the same)
http://man.exherbolinux.org/syd.7.html#Enhanced_Security_for_Memory_File_Descriptors
9. Enhanced symbolic link validations and procfs/devfs limitations:
(count how many proc fds leaks or magic symlinks caused podman CVEs, then please look at a mirror and laugh at yourself, mmkay?)
http://man.exherbolinux.org/syd.7.html#Enhanced_Symbolic_Link_Validation
http://man.exherbolinux.org/syd.7.html#Hardened_procfs_and_devfs
> Not that this is reason enough not to take it seriously. But the blog entry
> we need doesn't compare it to esoteric tech in Gentoo (which no one uses).
> It's a comparison between it and Youki that explains how each of the points
> under "capabilities" is different from Youki which doesn't use a
> "unikernel" and claims many of the same capabilities (because as you said,
> they're all using user-namespaces, cgroups, and secgroups under the hood).
Most of this paragraph is being completely ignorant and claiming all the world
is made up of containers. That said, I'll clarify one important thing for me:
The reason I call the new syd a unikernel is because it executes the system calls
on behalf of the sandbox process and as such is not vulnerable to TOCTTOU
as its historic alternatives, such as GsWTK and SysTrace.
> --
> Evan Carroll - me@...ncarroll.com
> System Lord of the Internets
> web: http://www.evancarroll.com
> ph: 281.901.0011 <+1-281-901-0011>
Finally, sorry if this was offensive. This is my last reply here unless
you start actually reading things and making sense for a change.
Best regards,
Ali Polatel
Download attachment "publickey - alip@...sys.org - 0xC22DA9DE.asc" of type "application/pgp-keys" (637 bytes)
Download attachment "signature.asc" of type "application/pgp-signature" (344 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
