Hacker News Reader

Comment by seeknotfind | Hacker News Reader

One big example is home folder access. Linux has a variety of file access control systems (the most prominent are Linux file permissions and SELinux). However, typically any application you run will be run under your own user and have access to your home folder.

In macOS/Windows, there are runtime permissions these days which allow you to control which folders can be given to which application.

Linux needs to mainstream a solution like this. One of the most popular way Linux users can handle this today is by associating a user with a application and granting various permissions to that user. However this is a far cry from safe by default, and it requires deep system knowledge.

View on HN

Once you own the home folder you can drop aliases for anything you want in the bashrc with almost no one noticing. At that moment point you are essentially done in almost all cases even in the absence of a local root exploit which Linux continues to be rife with. You will eventually catch a sudo password (using a trivial sudo wrapper alias) and all the ssh keys and jump host or password manager config.

Of course - the point is not to get the home folder owned.

There is no reason why Evince/Okular or mpv (to name a few apps which handle files with complex formats from untrusted sources) should have the right to access anything beside their ~/.config/<application_name> and the file they are currently viewing/playing, or maybe read-only ~/Music. If you want to do a "Save as", you will do this through a OS-controlled file dialog, or save it to /tmp and copy it.

This can be achieved with AppArmor, with a caveat that in X, applications can steal each other's windows, but unfortunately this is not the default and easy configuration on most distros.

Moreover, even if the user manages to deny you root access through excellent hygiene, that just means you can't include this machine in your botnet. You still have full view of the home folder! Upload to a data broker, get $.

I guess it would make sense to make bashrc, zshrc, whatever immutable to all but root. Never really considered that before. Allowing them to be edited is like allowing you to install or edit binaries anywhere in your $PATH.

There are many more files that will need this protection:

- autorun and keyboard shortcuts of your window manager -- one can hook an evil command to Ctrl+C

- ~/.mozilla -- you can add arbitrary javascript to your profile or extensions

- any application which does not expect to have its config externally tampered with and this may result in various errors including RCE

- ~/work/FooProject/Makefile, configuration of your IDE (which contains list of commands that shall be executed to compile)

etc.

An explicit allowlist would be a better option, IMHO perfectly manageable - with a popup window "the app wants to access <file>, allow once | allow permanently | deny".

> In macOS/Windows, there are runtime permissions these days which allow you to control which folders can be given to which application.

I know about this feature on macOS, but how do you configure this on windows?

I’ve seen the protected folders feature or something like that. But that’s not “which app can access which folder”. Rather, “only this list of apps can access this list of folders”.

I think there is also bubblewrap which flatpak uses, which can limit access to folders, and also XDG desktop portal which allows GUI applications to access files that are not available to them. Not sure if these are widely used though, iirc a lot of flatpak packages just have "normal" permission. Also, these are not very helpful for CLI applications.

Reply on news.ycombinator.com