Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

hardenedbsd.org

Post reply on HN
Print view View original

71–80 of 81 posts

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#71

Post by ori_b »

ruthmarx wrote: post #70
ori_b wrote: post #69

Earlier quoted context omitted.

> I think this is true for simple programs, and less true the more complex a program is. Chrome and Firefox have both been successfully pledged and unveiled. What programs more complex than them are you considering?

I gave examples at the end of my previous reply.

> Say, running an instance of Oracle, or a torrent program that by it's nature constantly needs to make network connections and write/read different files?

Yes, those seem relatively simple to pledge (source availability aside); there are a lot of permissions that they should be able to drop once they decide on, say, where the database lives or what files they're saving to. It gets even better if you're willing to privsep the torrent program, though that could take some refactoring.

Note that you can trivially do a looser sandbox around unmodified processes using exec pledges and unveil, even for proprietary code. These kinds of sandboxes need to be permissive, though, since they're not aware of program phases. So they're not nearly as tight as a sandbox written by the developer with knowledge about expected program behavior.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#72

Post by ruthmarx »

ori_b wrote: post #71
ruthmarx wrote: post #70

Earlier quoted context omitted.

I gave examples at the end of my previous reply.

> Say, running an instance of Oracle, or a torrent program that by it's nature constantly needs to make network connections and write/read different files? Yes, those seem relatively simple to pledge (source availability aside); there are a lot of permissions that they should be able to drop once they decide on, say, where the database lives or what files they're saving to. It gets even better if you're willing to pr…

> It gets even better if you're willing to privsep the torrent program, though that could take some refactoring.

Now you're talking about modifying the code substantially which is out of scope of the thought experiment.

Pledge can't really help with the torrent program since it needs to make new network connections and write and read arbitrary files constantly. Unless as you say, you substantially modify the code.

If substantially modifying the code is off the table, can you give an example of how pledge can prevent an attacker leveraging an RCE in the torrent program? To what extent would they be restricted? You can't say, limit execution to only certain files/libraries or restrict the ability to delete or overwrite files, right?

> Note that you can trivially do a looser sandbox around unmodified processes using exec pledges and unveil, even for proprietary code. These kinds of sandboxes need to be permissive,

Yeah, I wouldn't consider that to be a sandbox. Imposing limitations on a program isn't by itself a sandbox, nor is every instance of doing so sandboxing.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#73

Post by ori_b »

ruthmarx wrote: post #72
ori_b wrote: post #71

Earlier quoted context omitted.

> Say, running an instance of Oracle, or a torrent program that by it's nature constantly needs to make network connections and write/read different files? Yes, those seem relatively simple to pledge (source availability aside); there are a lot of permissions that they should be able to drop once they decide on, say, where the database lives or what files they're saving to. It gets even better if you're willing to pr…

> It gets even better if you're willing to privsep the torrent program, though that could take some refactoring. Now you're talking about modifying the code substantially which is out of scope of the thought experiment. Pledge can't really help with the torrent program since it needs to make new network connections and write and read arbitrary files constantly. Unless as you say, you substantially modify the code. If…

> Pledge can't really help with the torrent program since it needs to make new network connections and write and read arbitrary files constantly. Unless as you say, you substantially modify the code.

Unveil helps with the "arbitrary files" part. There's a reason Linux is cloning that interface with landlock.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#74

Post by ruthmarx »

ori_b wrote: post #73
ruthmarx wrote: post #72

Earlier quoted context omitted.

> It gets even better if you're willing to privsep the torrent program, though that could take some refactoring. Now you're talking about modifying the code substantially which is out of scope of the thought experiment. Pledge can't really help with the torrent program since it needs to make new network connections and write and read arbitrary files constantly. Unless as you say, you substantially modify the code. If…

> Pledge can't really help with the torrent program since it needs to make new network connections and write and read arbitrary files constantly. Unless as you say, you substantially modify the code. Unveil helps with the "arbitrary files" part. There's a reason Linux is cloning that interface with landlock.

> Unveil helps with the "arbitrary files" part.

How? The torrent program needs read and write access to create whatever files it needs to, which can't be predicted ahead of time.

Imagine a worst case scenario for an RCE in a torrent program, and then what is your best case scenario for pledge and unveil being able to confine an attacker?

Because I'm pretty sure it would be a lot less restrictive than what proper sandboxing can provide.

> There's a reason Linux is cloning that interface with landlock.

Sure, because it has advantages as part of defense in depth. I never said it was useless or without value.

Besides that, from memory landlock actually preceded unveil having started development in 2016, so I don't know that it's fair to say Linux is cloning anything if they had a solution first.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#75

Post by ori_b »

ruthmarx wrote: post #74
ori_b wrote: post #73

Earlier quoted context omitted.

> Pledge can't really help with the torrent program since it needs to make new network connections and write and read arbitrary files constantly. Unless as you say, you substantially modify the code. Unveil helps with the "arbitrary files" part. There's a reason Linux is cloning that interface with landlock.

> Unveil helps with the "arbitrary files" part. How? The torrent program needs read and write access to create whatever files it needs to, which can't be predicted ahead of time. Imagine a worst case scenario for an RCE in a torrent program, and then what is your best case scenario for pledge and unveil being able to confine an attacker? Because I'm pretty sure it would be a lot less restrictive than what proper sand…

> How? The torrent program needs read and write access to create whatever files it needs to, which can't be predicted ahead of time.

The same way it was handled in Firefox, for example; unveil the output dir. At least my torrent program doesn't shit files all throughout my file system. Maybe yours does?

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#76

Post by ruthmarx »

ori_b wrote: post #75
ruthmarx wrote: post #74

Earlier quoted context omitted.

> Unveil helps with the "arbitrary files" part. How? The torrent program needs read and write access to create whatever files it needs to, which can't be predicted ahead of time. Imagine a worst case scenario for an RCE in a torrent program, and then what is your best case scenario for pledge and unveil being able to confine an attacker? Because I'm pretty sure it would be a lot less restrictive than what proper sand…

> How? The torrent program needs read and write access to create whatever files it needs to, which can't be predicted ahead of time. The same way it was handled in Firefox, for example; unveil the output dir. At least my torrent program doesn't shit files all throughout my file system. Maybe yours does?

I meant arbitrary files within the dir. Not including any other dirs/files it has to read. So basically, it's marginally more effective than a chroot, without any real granularity.

Besides, you avoided the hard question:

Imagine a worst case scenario for an RCE in a torrent program, and then what is your best case scenario for pledge and unveil being able to confine an attacker?

Because I'm pretty sure it would be a lot less restrictive than what proper sandboxing can provide.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#77

Post by ori_b »

ruthmarx wrote: post #76
ori_b wrote: post #75

Earlier quoted context omitted.

> How? The torrent program needs read and write access to create whatever files it needs to, which can't be predicted ahead of time. The same way it was handled in Firefox, for example; unveil the output dir. At least my torrent program doesn't shit files all throughout my file system. Maybe yours does?

I meant arbitrary files within the dir. Not including any other dirs/files it has to read. So basically, it's marginally more effective than a chroot, without any real granularity. Besides, you avoided the hard question: Imagine a worst case scenario for an RCE in a torrent program, and then what is your best case scenario for pledge and unveil being able to confine an attacker? Because I'm pretty sure it would be a…

> Imagine a worst case scenario for an RCE in a torrent program, and then what is your best case scenario for pledge and unveil being able to confine an attacker?

Preventing exfiltration of any data outside of the downloads dir. Preventing execution of new programs. Preventing inspection, tracing, and signaling of existing ones. Preventing mmap of writable executable memory for shell code. And preventing pivoting exploits using system interfaces like vulnerable sysctls, large subsystems like drm, and so on.

This much can be done without touching the program code, or even binary, at all, using unveil and exec pledges.

If you're willing to refactor the code a bit, you can also prevent new sockets from being opened and new addresses from being listened on if the code doing networking is isolated from the code doing disk I/O.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#78

Post by ruthmarx »

ori_b wrote: post #77
ruthmarx wrote: post #76

Earlier quoted context omitted.

I meant arbitrary files within the dir. Not including any other dirs/files it has to read. So basically, it's marginally more effective than a chroot, without any real granularity. Besides, you avoided the hard question: Imagine a worst case scenario for an RCE in a torrent program, and then what is your best case scenario for pledge and unveil being able to confine an attacker? Because I'm pretty sure it would be a…

> Imagine a worst case scenario for an RCE in a torrent program, and then what is your best case scenario for pledge and unveil being able to confine an attacker? Preventing exfiltration of any data outside of the downloads dir. Preventing execution of new programs. Preventing inspection, tracing, and signaling of existing ones. Preventing mmap of writable executable memory for shell code. And preventing pivoting exp…

> Preventing exfiltration of any data outside of the downloads dir.

Except for all the data it needs access to. I'm not so sure torrent programs will continue to function correctly if they can't re-read their config file, in my experience most want access to a temp directory, the ability to run a few external applications like rar or zip, etc. Most torrent programs need access to more than just the directory where downloads end up when complete.

> Preventing execution of new programs.

This gets spicy if the torrent program is written in an interpreted language like python, no?

I honestly don't have much faith in how far unveil/pledge can restrict in this scenario, but as a result of this discussion I now have an OBSD box again so I can test and play around with it.

> If you're willing to refactor the code a bit

That's beyond the scope of the question. It's bad enough there is no mechanism to sandbox binaries where you don't have access to the code, talking about rewriting programs to solve the issue is some kobayashi maru nonsense.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#79

Post by lattera »

loeg wrote: post #60
BSDobelix wrote: post #47

Earlier quoted context omitted.

Your example is 9 years old (2015) when the project was less than 1 year old: https://hardenedbsd.org/content/about It also sounds like the person wants to promote his own "ElectroBSD", but just in the form of a patch-sets because of "unresolved license issues" he reallyreally wants his GPL-Code in BSD: https://www.fabiankeil.de/gehacktes/electrobsd/

The date really doesn't matter, I promise. It's representative of the overall quality. And HBSD has been defunct/inactive for some of those 9 years, possibly the majority of them -- the 2nd developer left 5 years ago, for example.

HardenedBSD has never been defunct or inactive.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#80

Post by lattera »

loeg wrote: post #5

Read these claims with a pretty big asterisk. Implementation quality of HBSD features is often poor or very poor. https://www.fabiankeil.de/gehacktes/hardenedbsd/ is just one example. Specifically some of the changes made to "harden" the system are pretty dubious and introduce new bugs, possibly security relevant, that did not previously exist. No one runs or pen tests HBSD. It's even more niche than OpenBSD.

Could you point me to some of the current changes that have made the system buggy? If HardenedBSD's features do introduce bugs, they should be fixed.
Post reply on HN