Hacker News Reader

Comment by radiator | Hacker News Reader

Pro: A website can never steal your SSH keys, because firefox is limited, via unveil(2), to only seeing your ~/Downloads folder.

Con: Every time you need to upload a file using your browser, you have to move it to this folder first.

View on HN

You can do similar things in Linux with firejail, but there are a lot of folks who feel uneasy about the safety of firejail.

Besides firefox, more than 80 userland programs have their access to the filesystem restricted with the use of unveil.

If Theo stopped being so resistant to solutions like AppArmor, then OpenBSD could have a real security layer instead of toys like unveil and pledge.

Here is Justine's write up on pledge and why he wants to port it to Linux. https://justine.lol/pledge/

It has its uses I guess, but it requires opt-in which is a pretty big disadvantage, and then still can't do even a fraction of what SELinux can already do. SELinux isn't that hard to learn, and the security benefits are immense.

    2024-01-08 22:34 ubuntu@knope:~$ sudo apparmor_status
    apparmor module is loaded.
    185 profiles are loaded.
    104 profiles are in enforce mode.
    (...)
    124 processes have profiles defined.
    122 processes are in enforce mode.

including firefox and chromium

But apparmor is more complex system and in fact is an RBAC. unveil(2) is much more easier in implementation and enforcing.

Also, there's AppArmor which is enabled in Debian and SuSE which transparently limits applications' reach without they realize.

Transparent limitation is a double-edged sword. From an adversarial perspective, it's good since I'm not advertising what my system can and can't do, and poorly written software may get hung up on timeouts waiting for things to happen. On the other hand, those same benefits against an adversary are negative constraints to usability, as now silent failures can happen on a system, requiring you to watch your AppArmor logs like a hawk when using new software.

Ultimately, less of a concern for servers that likely have limited scope and use cases, but a significant decrease in usability for workstations.

You need to write an AppArmor profile to limit your software. It’s an opt-in system.

The workflow is you put a test system to “complain” mode and use your software as intended, and add the required permissions to the profile by looking at the logs to see what your app is doing. Then you put AppArmor to enforcing mode, add the profile to production system and your application is sandboxed. Iteratively refine as necessary.

Debian desktop comes with AppArmor enabled. Nothing has been broken so far.

And every time you upgrade to the next major release, you start again from square one because the requirements of your software have changed. You get it to work and things seem to be fine. Over time, you start noticing things that are subtly broken, until something just fails completely and doesn't work. The fix turns out to be trivial when you give it another go two days later, but at the time it happened you really didn't have the nerve to deal with it right then.

After two dist upgrades, you realize that this approach isn't workable.

> And every time you upgrade to the next major release, you start again from square one because the requirements of your software have changed.

Nah. That's a huge exaggeration. Most software doesn't change its base behavior like that and certainly not with every new release, and certainly browsers don't.

Well, I have two Debian desktop installations. One is six, the other one is ten years old. I never had a problem with either.

This is without adding the numerous servers which I just install and forget, and they work without any problems for years.

edit: Yes, they're dist-upgraded all the time.

Unveil looks like a hack or a patch. Why do applications have access to whole filesystem by default?

Because there's already UNIX file permissions which prevent applications to reach places they shouldn't. Confine a daemon to its own user, chroot it, and it's a sitting duck in its own universe.

You add more layers with cgroup/AppArmor/SELinux in Linux, Jails in FreeBSD, unveil on OpenBSD, etc.

You harden as much as necessary. Not "drowned by default".

> Because there's already UNIX file permissions which prevent applications to reach places they shouldn't

Right. Just set up a separate user for Firefox using a single unprivileged command from your user account or a few clicks in your DE, then launch Firefox as that user using another single command or click. Being subordinate to your main user account, the Firefox user's files and directories can easily be managed from your main user and you can move files between subordinate users using just an (unprivileged) chown or chgrp. Accidentally launching applications as your main user is not possible and the system strongly encourages you to create separate, subordinate users for all your applications and is designed from the ground up to make this simple and it works out of the box.

Oh wait, that's not even remotely how any of this works. On a workstation, the "user account" is an almost completely useless concept (as set up and implemented in reality). That's why we have jails/namespaces/etc. Hacks that are piled on top of the useless mess of "user accounts" (all running as the same user, on workstations) trying to solve the same problems, but ultimately failing at providing any kind of comprehensive solution with a coherent vision. Software cannot take anything for granted anymore. Anything that looks like a writable file could be a read-only bind mount. Any mundane syscall could get it SIGKILLed for no reason other than that somebody forgot to add it to the whitelist. But from the user's perspective, there's no reasonable level of security by default.

Considering how we use jails/namespaces and other similar technology, your analogy sounds off. First of all, security is always set up in layers. A different user and chroot doesn't exclude the use of jails, or other kernel level security systems like AppArmor/SELinux. They are layered on top of each other as necessary.

Also, namespaces is not solely a security mechanism. Yes it allows isolation, but it allows resource limitation, too. So you can partition your system to slices and show a particular set of resources to an application (I'm sure you're way more knowledgeable than me in that regard).

On the other hand, security starts with application itself. Then you start to add extra containment barriers if you don't trust the software in question.

What I understand is our realities are completely disparate, and this is not how we hold the mechanisms I talk about. This might be due to the environment each of us live in, or due to our requirements, I don't know.

But, what I know is, the state of security is not as bleak as you portray, and necessity is mother of invention. Except SELinux, AppArmor, and FireJail all of the technologies we talk here are essentially built as virtualization, or virtualization-like technologies. They bring additional security as a secondary effect, and they're good at that.

> Software cannot take anything for granted anymore.

This is why we have stat calls, defensive programming, APIs and exception handling. The first rule of system programming is to never take anything for granted.

I have reached to the end of the time I have for today,

Have a nice day and a nice year.

I guess it has always been like this in Unix, but also in other Operating Systems.

You can edit /etc/firefox/unveil.main and add string like "~/Documents rwx" so it would be available from firefox

"To upload a file move it to your downloads directory" lmao

Can you "unveil" more places, without recompiling?

It would have cost them nothing to unveil a hypothetical ~/Uploads directory in the process of patching it to unveil ~/Downloads

You can trivially-easily add it yourself by editing a text file, unveil is configurable per-process.

True, but defaults are worth a million

With what purpose? Why do you want two different directories? On second thought, maybe you mean ~/Uploads could be unveiled read-only, though I still don't believe this brings much.

Yes, configurable in /etc/firefox/unveil.main

Reply on news.ycombinator.com