On Tue, Mar 11, 2025 at 11:18:49PM +0000, Tingmao Wang wrote: > On 3/11/25 19:28, Mickaël Salaün wrote: > > On Mon, Mar 10, 2025 at 12:39:04AM +0000, Tingmao Wang wrote: > > > On 3/6/25 03:05, Tingmao Wang wrote: > > > [...] > > > > This is also motivated by the potential UX I'm thinking of. For example, > > > > if a newly installed application tries to create ~/.app-name, it will be > > > > much more reassuring and convenient to the user if we can show something > > > > like > > > > > > > > [program] wants to mkdir ~/.app-name. Allow this and future > > > > access to the new directory? > > > > > > > > rather than just "[program] wants to mkdir under ~". (The "Allow this > > > > and future access to the new directory" bit is made possible by the > > > > supervisor knowing the name of the file/directory being created, and can > > > > remember them / write them out to a persistent profile etc) > > > > > > Another significant motivation, which I forgot to mention, is to auto-grant > > > access to newly created files/sockets etc under things like /tmp, > > > $XDG_RUNTIME_DIR, or ~/Downloads. > > > > What do you mean? What is not currently possible? > > It is not currently possible with landlock to say "I will allow this > application access to create and open new file/folders under this directory, > change or delete the files it creates, but not touch any existing files". > Landlock supervisor can make this possible (keeping track via its own state > to allow future requests on the new file, or modifying the domain if we > support that), but for that the supervisor has to know what file the > application tried to create, hence motivating sending filename. This capability would be at least inconsistent, and dangerous at worse, because of policy inconsistencies over time. A sandbox policy should be seen over several invocations of the same sandbox. See related deny listing issues: https://github.com/landlock-lsm/linux/issues/28 Let's say a first instance of the sandbox can create files and access them, but not other existing files in the same directory. A second instance of this sandbox would not be able to access the files the same application created, so it will not be able to clean them if required. That could be OK in the case of the ~/Downloads directory but I think it would be weird for users to not be able to open their previous downloaded files from the browser, whereas it was allowed before. For such use case, if we want to avoid new browser instances to access old downloaded files, I'd recommand to create a new download directory per browser/sandbox launch. > > (I can see this kind of policy being applied to dirs like /tmp or my > Downloads folder. $XDG_RUNTIME_DIR is also a sensible place for this > behaviour due to the common pattern of creating a lock/pid file/socket > there, although on second thought a GUI sandbox probably will want to create > a private copy of that dir anyway for each app, to do dbus filtering etc) An $XDG_RUNTIME_DIR per sandbox looks reasonable, but in practice we also need secure proxies/portals to still share some user's resources. This part should be implemented in user space because the kernel doesn't know about this semantic (e.g. DBus requests).
