I'd also be interested in this, particularly in the "move" case, which requires no privileges and can also happen without the kernel being in the loop (e.g. on a different machine, in NFS).
If your calculated policy is a function of the entire path, you'd normally need to key the calculated policy by the entire path and its relevant properties (underlying inodes) as well, no?
There are path-based LSMs in the Linux kernel that do not employ such caching. If you found a solution for this which also works in the corner cases and results in speed-up in real life scenarios, I'd be interested :)
When project leads and directors only ask for features,
the humans start to eventually push back,
but agents do as you please, no matter what the cost.
They were trained to do what you ask,
but unlike with humans, you need to ask for the refactoring yourself.
-- They won't necessarily come up with it on their own.
(They also tend to not be around for long enough to live through the consequences of their tech debt actions.)
Point taken, that's true. I'm admittedly developing on distributions where the updates are faster, so I missed that. But then again, I also didn't expect that this short weblog article would have such a large audience when I wrote it. :)
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.
I suspect the easier option is to use AI to review your own code. The arms race between developers and attackers might even make some of the AI valuations come true.
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)
If the logs are being read by agents then they should be more detailed and verbose to help the agent understand the root cause. We reduce the volume of information for humans. That doesn’t need to be the case any longer.
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.
First, they should move to GitHub or GitLab (or Codeberg) to attract more contributors and make the process of development easier. Maybe it could also be ported to support Wayland and Unicode properly, and remove some legacy code to ease up the maintenance.
The "Unix Power Tools" book is an excellent source for Unix and shell usage tricks
reply