gnoack

Yes, "en-bugging" :)

+1

It is also a testament to solid engineering and attention to good security practices in general. These still work, also against fancy new AI attackers.

When sophisticated attacks become cheaper to run, maybe it will (finally) be cheaper to do more solid engineering instead of doing it quick and dirty and ending up in indefinite bug-squashing mode.

How does this change the point that is being made in the article? Your agent is also only taking one of the existing roles that humans today occupy (e.g. the software operator or developer)

Those are pathname UNIX domain sockets, so you address them through the socket file, which is conventionally stored somewhere under /run.

You can run "netstat --listening --unix" to list the UNIX domain servers on your system, to get an impression.

See https://man7.org/linux/man-pages/man7/unix.7.html

I think you are misrepresenting this;

Varlink is based on much more conventional UNIX technology than Dbus, which is decades old: You connect to a named UNIX socket through its socket file in the filesystem (man page: unix(7)).

This is an old mechanism and it is known to work well. It does not require a broker service, it works right at system startup, and it does not require a working user database for permission checks (which would be a circular dependency for systemd in some configurations). If at all, I am surprised that systemd didn't use that earlier.

The main thing that Varlink standardizes on top of that is a JSON-based serialization format for a series of request/response pairs. But that seems like a lightweight addition.

It also does not require kernel support to work, the kernel support is already there. He mentioned in the talk that he'd like to be able to "tag" UNIX sockets that speak varlink as such, with kernel support. But that is not a prerequisite to use this at all. The service discovery -- and he said that in the talk as well -- is simply done by listing socket files in the file system, and by having a convention for where they are created.

Etoile had its own Smalltalk dialect back in the day, Pragmatic Smalltalk. This was a Smalltalk based on the Objective-C runtime, based on an OMeta implementation and a LLVM backend. David Chisnall, who created it at the time, ended up getting involved more in LLVM in the long run, I believe.

CDE was open sourced a while back: https://sourceforge.net/projects/cdesktopenv/

Absolutely, seccomp is also an unprivileged sandboxing mechanism in Linux. It does have the drawback however that the policies are defined in terms of system call numbers and their (register value) arguments, which complicates things, as it is a moving target.

The problem was also recently discussed at https://lssna2025.sched.com/event/1zam9/handling-new-syscall...

Landlock is currently still lacking some wrapper libraries that make it easier to use, in C.

We do have libraries for Go and Rust, and the invocation is much more terse there, e.g.

  err := landlock.V5.BestEffort().RestrictPaths(
      landlock.RODirs("/usr", "/bin"),
      landlock.RWDirs("/tmp"),
  )

Similarly terse APIs as for Go and Rust are possible in C as well though, as wrapper libraries.

For full disclosure, I am the author of the go-landlock library and contributor to Landlock in the kernel.

The way I interpreted most of these "subclassing" cases in the GoF diagrams was actually as "subtyping", and then it makes more sense.

Regarding no one having a lock on the term "delegation", I think this is spot on. Yes, someone might have used the term differently before GoF, but that does not mean that GoF was wrong. It just meant something else in their context.

(Btw, congratulations, your comment is the first one so far in this comment thread that actually discusses the linked article and not just the GoF book itself.)

It's tracked in https://github.com/landlock-lsm/go-landlock/issues/35 - signals and abstract Unix sockets do unfortunately not interact well with the inherently multithreaded Go runtime. We are working on a fix in https://github.com/landlock-lsm/go-landlock/issues/36 but this needs to be on the kernel side and this is delaying this feature in Go, unfortunately. It is usable from (single threaded) C programs though.

+1

A rough description of upcoming network restriction features in Landlock and how they map to the BSD socket API is in the talk at https://youtu.be/K2onopkMhuM?start=2025 starting around 33:45

I really hope we can get back to these features soon :) I think these would be very useful.

(Author of go-Landlock here)

Awesome! I'm happy to hear that you and others are interested in the configuration language. We should probably coordinate that on the Landlock mailing list when the time comes, so that we don't duplicate that work. We are open to outside contributions :)

OpenBSD did get it right, but they also have a more relaxed scheme for backwards compatibility across releases. Linux's strict ABI compatibility guarantees complicate matters slightly, but with the right supporting library it becomes tolerable.

See the example at the top of the Readme at https://github.com/landlock-lsm/go-landlock

(Full disclosure, I am the author of that library)

FWIW, I do hope that we can motivate people to use Landlock in the same way as people use pledge on OpenBSD, as a lightweight self-sandboxing mechanism that requires fewer architectural changes to your program and results in more constrained sandboxes than Linux namespaces and other mechanisms do.

(Author of that library here)

It is a library, as already linked in the other comment: https://github.com/landlock-lsm/go-landlock

The landrun tool is built on the same library. We also provide an official library for Rust, and obviously you can do it from C as well.

I also collected some libraries for other languages at https://wiki.gnoack.org/SoftwareUsingLandlock (but I can not vouch for their quality in detail)

Exactly, for resource limits you can use setrlimit(2) or cgroups if needed.

(Landlock reviewer here)

Namespaces can also be used for sandboxing, but they have a series of problems. Most importantly, they require more substantial changes to your program that wants to sandbox itself, and the program has to jump through a series of hoops to get everything into the right state. It is possible, but the resulting program environment is in the end more unusual and the mechanisms for enabling unprivileged namespaces are making it difficult to use it for smaller use cases. (It involves re-execution of the program that wants to sandbox itself, whereas with Landlock, a small program can just install a Landlock policy during an early startup phase and continue with that.)

Controlling the rules through a separate process is not currently possible, but it was proposed earlier this month on the kernel mailing lists:

https://lore.kernel.org/all/cover.1741047969.git.m@maowtm.or...

I ended up building my own Wiki in Go at some point, although I use this mainly for my own smaller purposes. Description and demo instance at:

https://wiki.gnoack.org/UkuleleWeb

It takes very little resources on my Raspberry Pi and is built to be extensible and safe through its transparent way of storing wiki pages as markdown files.

I find this an offensive comment. The GIGO principle applies to documentation, and we would be in a much worse place if we didn't have the man page documentation written and reviewed by humans.

It is not the Debian package maintainer stepping down here, but the project maintainer.

This is the project that maintains the user-facing documentation for Linux itself.

Anyone who does system administration on Linux, who uses the command line, or who programs in C is relying on this documentation.

Also, it is not the Debian package maintainer stepping down, but the project maintainer.

I think this is a big misinterpretation of that Alan Kay quote, which was in response to https://news.ycombinator.com/item?id=11941656 - the author of that comment aims to create a programming language with a focus on "data processing".

Alan Kay has long wanted to "get rid of data" in programming, as described at http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...

The entire discussion that this Alan Kay quote is from has always been about the prominence of "data" as a central concept in programming, not about other aspects like privacy or "big data".

In "UNIX - A History and a Memoir", Brian Kernighan is telling the story of doing that in 1972 (chapter 4.5, about "Grep")

    grep '^[behilos]*$' /usr/dict/web2

This does not necessarily deserve to be imitated, but it is an experience that definitely stood out in my memory in how unusual it was: the dsmc backup utility. The tool boggled me enough at the time that I wrote about it on my weblog:

https://www.unix-ag.uni-kl.de/~guenther/unix-tools-for-real-...

The things you can make a startup from these days... I just use a one-liner in my ~/.XCompose file...

    <Multi_key> <e> <m> : "My Complicated Name <my.complicated.email@gmail.com>"

Bash aliases for specific ssh hosts are seldomly needed, you can just as well configure hostname aliases in your .ssh/config file

In the mid-2000ds, there eventually came a time when the xlock (Ex-lock) screen locker disappeared from the last university workstations that still had it. People routinely got puzzled when they could not run it. It was a fun prank to tell them that Ex-Cee-lock was the replacement for it (which would, of course, run the clock application). :)

I'm puzzled.

It is a good thing that this works with empty makefiles, and it has probably worked from quite early on. :)

Subscribed. I like this explorative approach.

https://blog.gnoack.org/

Mostly Linux, Sandboxing, Go and sometimes other Unixy or programming language topics.

Not posting much, but with a high signal to noise ratio.