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

61–70 of 81 posts

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#61

Post by yjftsjthsd-h »

ruthmarx wrote: post #37
yjftsjthsd-h wrote: post #33

Earlier quoted context omitted.

> An externally imposed sandboxing feature isn't necessarily less restrictive than pledge and unveil at all, although I'm curious why you think that is the case. With pledge, you can read config files, open a file handle to your logs, and then completely drop the ability to open() files at all for the remaining lifetime of the program. How would you do that from outside the program?

By monitoring and intercepting what the program is doing?

I guess technically you could write a dynamic policy that... I guess you'd give it a list of files that the program can access exactly once? But that seems difficult and brittle. Is anyone actually doing that?

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#62

Post by saagarjha »

transpute wrote: post #59
saagarjha wrote: post #43

Earlier quoted context omitted.

I doubt it. Most humans do a pretty poor job at this already, and LLMs train on things other humans have written. If you have examples to the contrary for a novel mitigation I'd love to see it, but I will also only believe it when I see it.

Still useful for a formatted markdown table based on a specified list of non-novel mitigations.

Sure, but that’s not what we want here?

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#63

Post by ruthmarx »

transpute wrote: post #58
ruthmarx wrote: post #56

Earlier quoted context omitted.

I mean I don't see anywhere I can download the patches to apply them to a source tree locally.

git format-patch -29 HEAD --stdout > 0001-last-29-commits.patch

Interesting, thank you. I don't use git that much and my own searching turned up creating a patch that seemed like it required git to apply.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#64

Post by ruthmarx »

yjftsjthsd-h wrote: post #61
ruthmarx wrote: post #37

Earlier quoted context omitted.

By monitoring and intercepting what the program is doing?

I guess technically you could write a dynamic policy that... I guess you'd give it a list of files that the program can access exactly once? But that seems difficult and brittle. Is anyone actually doing that?

No, I suppose not, but then, is there really an advantage to doing so?

I'm much more concerned with blocking write and execute access than I am about a potential hacker being able to read the config files of the program they leveraged to get a shell.

I think it's a good approach and part of defense in depth, but if we're comparing approaches I'll tale the former every time.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#66

Post by transpute »

saagarjha wrote: post #62
transpute wrote: post #59

Earlier quoted context omitted.

Still useful for a formatted markdown table based on a specified list of non-novel mitigations.

Sure, but that’s not what we want here?

The HardenedBSD list isn't focused on novel mitigations, so LLM summary is possible. For the OpenBSD list, an LLM can help a knowledgeable reader to quickly separate the novel and non-novel mitigations, so that a human can focus on the novel mitigations.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#67

Post by ori_b »

ruthmarx wrote: post #64
yjftsjthsd-h wrote: post #61

Earlier quoted context omitted.

I guess technically you could write a dynamic policy that... I guess you'd give it a list of files that the program can access exactly once? But that seems difficult and brittle. Is anyone actually doing that?

No, I suppose not, but then, is there really an advantage to doing so? I'm much more concerned with blocking write and execute access than I am about a potential hacker being able to read the config files of the program they leveraged to get a shell. I think it's a good approach and part of defense in depth, but if we're comparing approaches I'll tale the former every time.

> No, I suppose not, but then, is there really an advantage to doing so?

A massive one; not reading the config is just a consequence of dropping all file system access once you're done with the initial program setup. You can also set up listening sockets, and then stop the program from making any new network connections, even after a compromise. And so on, with most resources. There are a lot of resources that tend to be needed to set up a program. There tend to be very few needed once the program is running.

How would you block all file system access after a program is finished reading its config files, the files they include, and the shared libraries and plugins scattered around the file system? How would you turn off all network access after the listening socket is established?

With Pledge, it's trivial:

    load_config();
    load_plugins();
    open_sockets();
    pledge(NULL, NULL);
    run();
Pledge makes everything you're talking about work trivially, the only thing that's needed is for the program to opt in to security with one line of code. You don't need to micromanage the permissions and what the program is doing to drop privileges from the outside, with all of the race conditions and fragility that implies.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#68

Post by ruthmarx »

ori_b wrote: post #67
ruthmarx wrote: post #64

Earlier quoted context omitted.

No, I suppose not, but then, is there really an advantage to doing so? I'm much more concerned with blocking write and execute access than I am about a potential hacker being able to read the config files of the program they leveraged to get a shell. I think it's a good approach and part of defense in depth, but if we're comparing approaches I'll tale the former every time.

> No, I suppose not, but then, is there really an advantage to doing so? A massive one; not reading the config is just a consequence of dropping all file system access once you're done with the initial program setup. You can also set up listening sockets, and then stop the program from making any new network connections, even after a compromise. And so on, with most resources. There are a lot of resources that tend t…

> There are a lot of resources that tend to be needed to set up a program. There tend to be very few needed once the program is running.

I think this is true for simple programs, and less true the more complex a program is.

What about programs that due to their nature need to frequently make new network connections, or to periodically check config files?

> How would you block all file system access after a program is finished reading its config files, the files they include, and the shared libraries and plugins scattered around the file system? How would you turn off all network access after the listening socket is established?

This could be done with seccomp, although it would be more work than it is to use pledge (although a pledge 'port' also exists), it could also be done with things like SELinux.

> Pledge makes everything you're talking about work trivially,

I was talking about more complete sandboxing, and pledge doesn't allow for that. Pledge is substantially more limited in scope.

> the only thing that's needed is for the program to opt in

That's actually a pretty big issue. If all the software you want to use is in the ports tree I guess it's fine, but what about for untrusted or complex code? 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? Pledge is little help in these cases, and especially ineffective as any attempt at sandboxing such applications.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#69

Post by ori_b »

ruthmarx wrote: post #68
ori_b wrote: post #67

Earlier quoted context omitted.

> No, I suppose not, but then, is there really an advantage to doing so? A massive one; not reading the config is just a consequence of dropping all file system access once you're done with the initial program setup. You can also set up listening sockets, and then stop the program from making any new network connections, even after a compromise. And so on, with most resources. There are a lot of resources that tend t…

> There are a lot of resources that tend to be needed to set up a program. There tend to be very few needed once the program is running. I think this is true for simple programs, and less true the more complex a program is. What about programs that due to their nature need to frequently make new network connections, or to periodically check config files? > How would you block all file system access after a program is…

> 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?

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#70

Post by ruthmarx »

ori_b wrote: post #69
ruthmarx wrote: post #68

Earlier quoted context omitted.

> There are a lot of resources that tend to be needed to set up a program. There tend to be very few needed once the program is running. I think this is true for simple programs, and less true the more complex a program is. What about programs that due to their nature need to frequently make new network connections, or to periodically check config files? > How would you block all file system access after a program is…

> 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.
Post reply on HN