News for hackers. Stuff that matters.
Re:Initial support for guided disk encryption in OpenBSD ins... by Zurrrrr on Wednesday March 08, 2023 @11:11PM (#35078243)
Haha, so you can't even answer the question lol. Yeah, it's clear you have no clue about SELinux at all.

What is with you and putting so much effort just to argue out of loyalty and emotion when you don't even know the thing you are arguing against, aside from assumptions?

Pledge is a goddamn toy and it's hilarious you think otherwise. Pledge isn't going to do ANYTHING to protect, say, a complex database server or any number of third party programs that need all kinds of access, and require being able to make all types of syscalls.

You've parroted my own reply back at me, without bothering to comprehend it or realize that it doesn't apply at all in the way you've bastardized it and tried to force it to.

You clearly, CLEARLY have no clue at all what you are talking about, and are basically just the OBSD version of a linux zealot stereotype.

In short, you're a tool. You clearly need to have the last word due to your ego, so have at it, but I won't waste my time by humoring you further. It's genuinely a shame I can't block you and will still be notified of whatever noise you make next.

Re:Initial support for guided disk encryption in OpenBSD ins... by ori_b on Thursday March 09, 2023 @10:34AM (#35082257)
> Pledge is a goddamn toy and it's hilarious you think otherwise. Pledge isn't going to do ANYTHING to protect, say, a complex database server or any number of third party programs that need all kinds of access, and require being able to make all types of syscalls.

Here's a program that will run an arbitrary command under the same restrictions as Chrome. Presumably, this counts as a complex third party program.

    #include <stdio.h>
    #include <unistd.h>
    #include <err.h>

    #define CHROME_MAIN_CONTENT_PLEDGE \
        "rpath wpath cpath stdio tmppath dns inet flock "
        "unix proc prot_exec tty sendfd recvfd exec mcast "
        "ps drm fattr route getpw vminfo video"

    int
    main(int argc, char **argv)
    {
        if(argc < 2)
                errx(1, "usage: %s cmd\n", argv[0]);
        if(pledge(CHROME_MAIN_CONTENT_PLEDGE, CHROME_MAIN_CONTENT_PLEDGE) == -1)
                err(1, "pledge");
        if(unveil("/var/empty", "r") == -1)
                err(1, "unveil");
        if(unveil(NULL, NULL) == -1)
                err(1, "unveil");
        execv(argv[1], &argv[1]);
        err(1, "exec");
    }
compile as:

     cc -o asroot asroot.c
run as:

    doas ./asroot your-exploit-command
What exploit command you do use to break out?
Re:Initial support for guided disk encryption in OpenBSD ins... by Zurrrrr on Thursday March 09, 2023 @01:15PM (#35084611)
That isn't the context of the conversation. You really are very disingenuous.

How about you show me how you lock down an OBSD system that is running, say Oracle. With pledge.

Re:Initial support for guided disk encryption in OpenBSD ins... by ori_b on Friday March 10, 2023 @09:23AM (#35094597)
You keep insisting that if you can run pledged and unveiled code as root, you can break out. Let's get that part of the discussion out of the way first, and then I'll happily switch tracks to pledging oracle.

Though I'm not sure why you think it'd be much harder than pledging Chrome or Firefox.

Re:Initial support for guided disk encryption in OpenBSD ins... by Zurrrrr on Friday March 10, 2023 @10:03AM (#35095148)
Oracle, and third party software was the example I used from the start. SELinux absolutely can protect Oracle or any complex program.

If you want t discuss this further, illustrate how pledge can protect against a remote root exploit in Oracle as good or better than SELinux can.

Re:Initial support for guided disk encryption in OpenBSD ins... by ori_b on Friday March 10, 2023 @10:15AM (#35095347)
Again, can you give an example of an jailbreak you're thinking of? So far, I don't even think you've given a clear explanation of your threat model. Once we have that, we can have a discussion about Oracle fits into it -- but until then, there's no substance.

What operations would you use to break out of the above sandbox? Once you give me that, I'll happily discuss the details.

Re:Initial support for guided disk encryption in OpenBSD ins... by Zurrrrr on Friday March 10, 2023 @10:29AM (#35095577)
Again, from the start, my scenario and example was third party software. Feel free to re-read the thread from the start if you want to confirm that.

I'm not interested in retreading anything. I don't even want to continue discussing anything with you as it is, but I'm willing to see where this goes.

Show how pledge can protect against a remote root compromise in oracle. I doubt it can, you've been insisting pledge is all OpenBSD needs to protect against such attacks.

I'm not answering any more questions or taking any more detours. Stop being intellectually dishonest.

Either admit that you don't know for sure that pledge can protect against a remote root compromise in complex third party software like oracle and simply think it can, or show how it can.

If you can't do that, we're at an impasse and there won't be further discussion. Unless you post some kind of baiting comment I suppose, which wouldn't surprise me at this point.

Re:Initial support for guided disk encryption in OpenBSD ins... by ori_b on Friday March 10, 2023 @11:02AM (#35096120)
You exec oracle with an unveil that prevents a compromised oracle from touching any data that you didn't intend, and an exec pledge that removes the ability to open any raw devices other than the ones you handed to it directly.

The program upthread will let you do that.

It won't be as good as Oracle doing its own pledges, of course, because well pledged programs narrow down their pledge set as they run -- but if you have a binary that you can't modify, this is as good as you can do with any security framework. For example, Linux has landed on the same model as pledge when they added landlock, where a program is expected to landlock itself after opening the initial handles to resources.

Re:Initial support for guided disk encryption in OpenBSD ins... by Zurrrrr on Friday March 10, 2023 @12:05PM (#35097285)
> You exec oracle with an unveil that prevents a compromised oracle from touching any data that you didn't intend, and an exec pledge that removes the ability to open any raw devices other than the ones you handed to it directly.

And if it needs access to an awful lot of data across the file system or raw devices (which is not uncommon for complex proprietary commercial software), what then?

> It won't be as good as Oracle doing its own pledges, of course

And that's part of the issue, because you can't count on or only use software which is making pledges, and no commercial software will at all.

> but if you have a binary that you can't modify, this is as good as you can do with any security framework.

This is where a MAC framework has a strength and advantage over pledge.

With pledge/unveil and oracle, you likely won't be able to sufficiently restrict access to data or devices to prevent lateral movement and prevent further compromise, as complex programs like that require too much access to function correctly.

With a MAC framework you can. Now the binary has no access to certain parts of the filesystem in a way that is much more secure than a chroot, only has access to syscalls it needs (on par with pledge here), can't execute other binaries, can't make library calls, can't access devices (e.g. tty, network), can't switch user context, can't do anything as root even if root were obtained, can't write to ANY files only append, can't delete ANY files, etc etc etc. You have complete granular control over many more aspects of what to permit or deny.

Pledge and unveil simply can't compare. In some scenarios they may be sufficient, but in most, and certainly in most where an attacker has root, they are not.

Re:Initial support for guided disk encryption in OpenBSD ins... by ori_b on Friday March 10, 2023 @01:48PM (#35099076)
> And if it needs access to an awful lot of data across the file system or raw devices (which is not uncommon for complex proprietary commercial software), what then?

The same thing as any other framework. You either grant it access, or you don't. The list of files just gets long.

> And that's part of the issue, because you can't count on or only use software which is making pledges, and no commercial software will at all.

Luckily, you can pledge and unveil from outside the process, as the code above does. Once more, that runs an arbitrary command under pledges and unveils.

The thing lost is the ability reduction in access during the program lifetime, which is something that can only be done with the cooperation of the binary running; you don't have enough information to know when (for example) the code setting up the last network listener needed has been run without the help of the binary. You don't get that in most security frameworks anyways, so this is not a weakness in comparison to them.

> With a MAC framework you can. Now the binary has no access to certain parts of the filesystem in a way that is much more secure than a chroot, only has access to syscalls it needs (on par with pledge here), can't execute other binaries, can't make library calls, can't access devices (e.g. tty, network), can't switch user context, can't do anything as root even if root were obtained, can't write to ANY files only append, can't delete ANY files, etc etc etc. You have complete granular control over many more aspects of what

Yes, that's what you get with pledge and unveil.

If you think otherwise -- I gave you a program that runs any arbitrary binary; please show a demo of a jailbreak.

Re:Initial support for guided disk encryption in OpenBSD ins... by Zurrrrr on Friday March 10, 2023 @03:36PM (#35100610)
> The same thing as any other framework.

No. Not even close. You're missing the point.

There is a fundamental difference which you are ignoring or blind to.

With something like pledge, you can't limit anywhere near as much as what you can limit with a MAC framework.

This means with pledge, you can only limit to what the program needs, which may well be enough (and with something like Oracle it's almost guaranteed) for an attacker to escape whatever confines you think you have in place. That simply isn't true for a MAC framework where you can limit to a greater extent and with a lot more granularity.

> Luckily, you can pledge and unveil from outside the process, as the code above does.

That doesn't help even slightly and has no bearing on the point I made.

> Yes, that's what you get with pledge and unveil.

Jesus christ no you don't. Not even close. At this point it's abundantly clear you are not familiar with MAC frameworks at all, and you're just convinced that pledge and unveil are the same thing. That's willful ignorance and nothing more.

> If you think otherwise -- I gave you a program that runs any arbitrary binary; please show a demo of a jailbreak.

You haven't shown that pledge and unveil are as good at SELinux at locking down something like Oracle, you're just claiming it is with hand waiving. pledge and unveil simply don't offer what SELinux does, and you're just dismissing that and insisting they do.

Ridiculous.

Re:Initial support for guided disk encryption in OpenBSD ins... by ori_b on Friday March 10, 2023 @06:51PM (#35103036)
> With something like pledge, you can't limit anywhere near as much as what you can limit with a MAC framework.

Go ahead, tell me a specific thing that I can't limit with pledge and unveil. Note that everything you mentioned when discussing Oracle could be done with them.

I've provided code. You haven't even listed a threat model. You just yelled a bit about root escapes, and then when challenged to provide an example, yelled about Oracle. And then yelled a bit about how MAC provides more, without any specifics about which relevant 'more' it provides. (I certainly agree that it's more flexible, more complicated, and more difficult to configure -- but not that it's more secure).

Again, there's example code sitting right there, which can be used for something like Oracle. Prove that there's an escape.

Re:Initial support for guided disk encryption in OpenBSD ins... by Zurrrrr on Friday March 10, 2023 @07:03PM (#35103180)
> Go ahead, tell me a specific thing that I can't limit with pledge and unveil. Note that everything you mentioned when discussing Oracle could be done with them.

Sigh. I've listed numerous examples, and like a dipshit you just change a few words in my reply and parrot it back at me, without seemingly comprehended a thing.

At this point you are just displaying zealotry. Even Theo disagrees with you.

> I've provided code.

Fucking exactly. That shows that you are not following the discussion at all, just blindly defending your niche OS.

We were talking about complex third party programs that are hard to lock down. A short code example using pledge is, now make sure you read these next few words and try to absorb them, entirely fucking irrelevant.

We're not talking about software developers trying to prevent exploitation of trusted code, we're talking about trying to lock down untrusted code in the event of a compromise.

> You just yelled a bit about root escapes, and then when challenged to provide an example, yelled about Oracle. And then yelled a bit about how MAC provides more, without any specifics about which relevant 'more' it provides.

No, I gave specific examples, and you just hand waived them and asserted pledge and unveil offer the same capabilities and defenses without bothering to show how.

> Again, there's example code sitting right there, which can be used for something like Oracle

No it fucking can't, at all, it's entirely irrelevant and has no relationship to oracle at all. Are you on the spectrum or something? How are you failing to follow this discussion to this extent? It's honestly baffling.

Re:Initial support for guided disk encryption in OpenBSD ins... by ori_b on Friday March 10, 2023 @07:05PM (#35103201)
> We were talking about complex third party programs that are hard to lock down. A short code example using pledge is, now make sure you read these next few words and try to absorb them, entirely fucking irrelevant.

That short code example LOCKS DOWN AN ARBITRARY THIRD PARTY PROGRAM that you pass it as a command line argument. I skipped arg parsing for simplicity, but it does exactly what you're asking for.

> No, I gave specific examples

Can you point to the code you posted that breaks out of the sandbox I gave? I seem to have missed it.

Re:Initial support for guided disk encryption in OpenBSD ins... by Zurrrrr on Friday March 10, 2023 @07:10PM (#35103250)
> That short code example LCOKS DOWN A COMPLEX THIRD PARTY PROGRAM. The fact that you haven't understood this shows that you're not understanding the discussion.

It doesn't do a fucking thing to lock down Oracle you absolute twit.

So, I'm going to go ahead and assume you are indeed on the spectrum at this point. Not that it matters. But once again you just parrot a point back at me lol.

Sigh. This is honestly so fucking stupid. Honestly you need a good slap at this point.

Pledge can ONLY restrict a program to the syscalls it needs. If the program needs syscalls which can be used to leverage an escape or escalation, pledge is fucking useless. SELinux doesn't have that weakness. That you don't understand this fundamental difference shows you're out of your depth, and that as suspected you're a waste of time to try and educate.

I'm not going to reply to you again given how technically illiterate you are in this context. Given how insecure and religious towards OpenBSD you seem to be, I'm assuming you're going to need to have the last word, and likely will yet again just parrot back a paraphrased version of one of my replies to you...yet again demonstrating your lack of originality or comprehension.

Have fun with that, and I hope having the last word gives you that little boost of self-confidence you seem to be craving to compensate for your clear lack of knowledge.

Best of luck to you in life. You need it.

Re:Initial support for guided disk encryption in OpenBSD ins... by ori_b on Friday March 10, 2023 @09:07PM (#35104364)
> It doesn't do a fucking thing to lock down Oracle you absolute twit. Oracle won't even start if you try to limit it as though it were Chrome.

Yeah, change the fucking #define I hardcoded for simplicity to match what Oracle needs. You'd probably want to remove the stuff that allows it to do graphics. Or make the config a command line argument.

For comparison, can you show me the SELinux policy that you would write to lock down Oracle, or Chrome, or Firefox, or some other complex third party piece of software with multiple processes and threads with different roles?

Re:Initial support for guided disk encryption in OpenBSD ins... by dang on Saturday March 11, 2023 @12:02AM (#35105542)
Yikes—you broke the site guidelines really, really, really badly, dozens of times in this thread. That's definitely not ok and I've banned the account.

I'm sure you know a lot and I normally wouldn't ban an account without warning at least once first, but the way you behaved in this thread was just way too extreme. I know this sort of no-holds-barred flamewar is standard in some systems-oriented communities and I don't have any judgment about that, but HN is much larger and we can't afford to have accounts posting like this—it would lead straight to the self-incineration of this site (by masses of people who likely know a lot less than you do).

If you don't want to be banned, you're welcome to email [email protected] and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.