logoalt Hacker News

mittenscyesterday at 6:32 AM1 replyview on HN

> Neither SELinux not AppArmor allows to show a question "would you like to allow program N to access your microphone"

Permissions on microphone device would work, build your own UI / virtual device or generate one with claude if you really want popups.

> "would you like to let the program connect to github.com? (Yes) (No) (With decrypting SSL traffic)"."

I actually have something for this. Firewall everything blocked, domains unblocked via DNS request if I allow them.

Linux is very powerful here compared to iOS - can you block specific domains there?

> The best you can do today is either write your own sandbox around Linux namespaces (very complicated), or try lightweight VMs like Firecracker, or paravirtualization (like VM but with a shared kernel).

What do you think the sandbox on ios/android is?, still a vm/namespace/container...

> require lot of work and programming.

Sure, but you learn.

> I want to install random packages and still be safe. That's the point of installing an OS, to be able to run random programs on the computer.

That's not true anywhere. I would not feel safe with random apks or random store entries on android OR iOS. On iOS i lived through the whole 'access a webpage to get jailbreak' phase... with no way around it since mandatory safari

So, other OSs just give you the impression of safety. And you're locked. (iOS with safari...)

On Linux you are free, up to your capabilities.


Replies

codedokodeyesterday at 7:36 AM

How do you sandbox /proc by the way? So that the app doesn't crash due to missing /proc/self/exe link or /proc/ID/stat file, but cannot read my private information (like /proc/cmdline, /proc/mounts etc)? Things like bind mounts do not work on /proc.

I ended up with writing a FUSE-based emulation in Python, but there are lot of issues with permissions and namespaces:

- I could run my /proc emulator in the same PID namespace as the target, but in a different mount namespace so that I can mount real /proc there. This is not safe because the target could send signals or ptrace my emulator and gain access to the real /proc. Especially if it is an AI agent, they are pretty capable.

- I could run the emulator in a different mount and PID namespaces but then the emulator needs to translate PIDs into the target namespace, and for this I need to know the format of all files and where they contain PIDs and it is a pain

- running the poorly coded emulator as a root is not an option. The sandbox must work without root.

- ideally the emulator should run as a different user because Linux provides the strongest isolation for processes of different users, but in this case I won't be able to access target's /proc entries.

Also, running a program is the most basic functionality of an OS and you suggest that I need to write my own sandbox to do this because it is not included with Linux. Maybe that is why this year still is not the year of Linux on desktop.