Hacker News new | comments | show | ask | jobs | submit login
Domesticating applications, OpenBSD style (lwn.net)
66 points by fcambus 791 days ago | hide | past | web | 41 comments | favorite

The spender character is an example of why I stay away from LWN comments. Too many narrow-minded, Linux-centrist commentators who are willfully ignorant or even have vendettas against anything outside their Linux bubble.

Otherwise, kudos on LWN for reporting this.

Wait, so when Theo says 'Some BPF-style approaches have showed up. So you need to write a program to observe your program, to keep things secure? That is insane.'

That is fine and dandy, but when someone criticizes Theo's work in the same scornful manner, it's suddenly 'narrow-minded', 'willfully ignorant' and part of a 'vendetta'.

Pot meet kettle.

Because Theo is right, having to write programs to observe programs is insane.

While spender is wrong for multiple reasons. Such as that /var is mounted nosuid on OpenBSD by default so their hypothetical "httpd chmod'ing to setuid" doesn't work ("nix" points this out to them but isn't aware of OpenBSD's defaults in this area). The other reason is they are decrying the whole system because of a fairly weak attack scenario (requires a local user account) and it's not like that attack isn't possible now, so while tame() doesn't protect against that specific thing it protects against others but spender is just saying nope, it doesn't protect against this specific scenario therefore it's useless.

Also if you keep reading spender's commenters they go on to claim OpenBSD's devs are delusional plagiarists so "vendetta" does seem appropriate.

Spender's point is that a capabilities-based approach does not really work for real-world scenarios, and he probably has a point. The setuid thing was more an example as I understood it.

While Spender's criticism isn't usually very diplomatic, he's often right.

Here's an example, this is QEMU's seccomp whitelist: http://git.qemu.org/?p=qemu.git;a=blob_plain;f=qemu-seccomp....

As you can see, it's mostly worthless since QEMU has to do lots of potentially-dangerous operations by design (even reading/writing to raw devices). A proper mandatory access control framework actually restricts which device files it can access, for example - as implemented in the AppArmor/SELinux sVirt drivers. Theo's approach is similarly flawed.

capabilities-based approach

tame() isn't a capabilities-based approach. Don't confuse POSIX capabilities with actual capability-based security. The former hijacked an existing term to refer to a different thing.

It's pretty obviously a limited API, but it also makes privilege dropping absolutely trivial. Which is the point.

> That is fine and dandy, but when someone criticizes Theo's work in the same scornful manner, it's suddenly 'narrow-minded', 'willfully ignorant' and part of a 'vendetta'.

Attacks on Theo are the opposite of interesting but that spender guy lashes out at his follow commenters:

Oh sorry, I forgot LWN readers require me to do all their homework for them

And so on.

I'm not sure what is going on when a guy who is apparently a professional pulls a from my parents basement in Wyoming I stab at thee! but it's not atypical of LWN comments.

On the other hand, there is plenty of useful stuff there sometimes. You take the bad with the good.

>I'm not sure what is going on when a guy who is apparently a professional pulls a from my parents basement in Wyoming I stab at thee!

While 'Oh sorry, I forgot LWN readers require me to do all their homework for them' comes across as a petty remark (though hardly as hateful as you try to paint it), I've read a lot worse from for example Theo who is also 'apparently a professional', and of course from countless other 'apparently professionals', in countless places beyond LWN, like right here on Hacker News (yes, really!).

Vezzy-fnord totally disregarded the tone in which Theo characterised existing solutions while painting this spender guy as some bully driven by narrow-mindedness because he came from a 'Linux bubble' and I assume therefore could not accept the brilliance of Theo's solution or something like that.

To me it seems like this spender guy is providing strong criticism against this solution from a practical perspective, and vezzy-fnord chose to paint him as a 'narrow-minded' and 'wilfully-ignorant' through his tone (again totally disregarding Theo's same tone) in order to sweep the technical criticism under the rug (don't listen to him, he is on a 'vendetta'!) .

> Vezzy-fnord totally disregarded the tone in which Theo characterised existing solutions

Vezzy-fnord was commenting on the quality of LWN comments.

It's as if you do not understand that Theo did not comment on that LWN page...

Sorry for late reply!

>It's as if you do not understand that Theo did not comment on that LWN page...

The comments in question where in large responses to Theo's claim, which in turn was part of the article on which the comments are based.

Vezzy-fnord used this to paint LWN comment section as being populated by narrow-minded, Linux-centric people with vendetta's, totally ignoring that the comments by 'spender' were perfectly in line with the comments typically uttered by Theo, whose solution was under discussion.

And as to further underline how this was all bs from start to finish on Vezzy-fnord's part, the guy in question (spender) who was making the aggressive criticism is not some Linux zealot, he is criticizing Linux security solutions in exactly the same manner.

Yeah, stuff like this reminds me of why OpenBSD even exists: because Theo got kicked out of NetBSD for being unable to stop making personal attacks on the mailing lists.

Spender is the originator/maintainer of the venerable grsecurity patch set, he knows a thing or twelve about this subject.

Are they person who runs the @grsecurity twitter account that seems terminally bitter about everything OpenBSD does?


Hm, I suppose then I can exclude him in particular, since it's clearly a battle between two infosec-oriented hotheads. My point about LWN comment quality stands, though.

LWN comments are an object of scorn even from purely Linux-oriented developers who present at conferences. It's almost a running joke lately on conference videos on Youtube.

spender rants angrily about everything and everyone including Linux as far as I have seen, so I don't think its fair assessment to say that his comments stem from some sort Linux bubble. spender is also hardly typical person, on LWN or outside.

I really like this solution. Far better than pissing around with SELinux configuration and it's well contained.

I'm... conflicted.

On one hand, a simple opt-in way for applications to give away the ability to do operations is something I've wanted for sandboxing for a long time. From an API perspective, tame() looks great.

However, the kernel-side implementation is way too ugly. Hardcoding pathnames needed to use things like DNS, NIS, etc is just way too inflexible and fragile.

I think the kernel should just support a set of fs/network/etc restrictions that can be grown but not shrunk by the process. i.e. basically what seccomp-bpf gives you on linux. What we really need is user-friendly libraries to make using seccomp-bpf as easy as using tame()!

I think it's quite simple really. Sure it's a bit ugly but most APIs are behind the scenes. As long as the API itself is clean, that's not necessarily a problem.

In this case though, the problem with growing the permission set is you then need rules to define the sandbox "size" outside the process, then tools to administer it, then the policies to be deployed with the program.

If you're using tame which is restrictive, based on how they do privsep in OpenBSD, you're forking tasks off from a control process and then removing privileges. So the program defines the policy internally, very granularly and correctly.

How you'd do that with seccomp-bpf with forked child processes etc would be vastly more complex. Consider OpenSMTPd for example which consists (I can't remember the exact separations): master process, smtp listener, queue, writer. These are all forked from the master process and talk to each other with pipes. How would you mandate the call limitations efficiently if this was externalised? Also how would you assure that a misapplied external policy doesn't compromise your system.

The problem isn't that it's behind the scenes, it's what part of it is in kernel space.

The user of tame() quite sensibly wants to specify a simple filter based on what things they might need to do in the future. i.e. "I need to be able to loop up details about local users". At the system-call level this implies a number of things should be allowed i.e. "can open /etc/group for read-only access, can read NIS configuration files, ..."

In the OpenBSD implementation of tame() all of these rules are hardcoded into the kernel. Using LDAP instead of NIS? Well, you'll have to patch and recompile I guess.

Since ultimately the userland process is opting-in to the restrictions there's no security reason that it can't specify the rules to the kernel. (Assuming here that care is taken so it can't DoS the kernel by pushing down a billion-entry list or something)

Again, what OpenBSD gets right here is the API -- it should be as simple as possible for a process to say "I need to look up users, use DNS, and read files; block all else" Making that a simple call like tame() is a great step forward. I hope the seccomp-bpf people do something similar.

However, tame() should be a library function, not a syscall. The kernel shouldn't know or care what "I need to use DNS" means, it should just be told what files I can open and what sockets ops I'm allowed to do.

The OpenBSD implementation is simultaneously too rigid for some things (since things like plugable nsswitch.conf modules can't work at all) and too loose to support other useful ones (per-application policies like "block any attempt to open a file for writing unless it's an append to $HOME/.ssh/known_hosts")

In UNIX there is a very long tradition of not baking policies like this into the kernel, and for good reason.

The kernel shouldn't know or care what "I need to use DNS" means, it should just be told what files I can open and what sockets ops I'm allowed to do.

Is this perhaps an artifact of the OpenBSD development model, where programs are assumed to work tightly coupled to the kernel?

It is probably more acceptable to OpenBSD than it would be in Linux, but it still doesn't feel like a good idea.

It shouldn't be. They're POSIX focused.

I conceed. Some good points there.

Of the pathnames contained in tame_namei(), how many are really going to change? I'm trying to think of a case where alternate names or paths are needed, yet nothing comes to mind.

Certainly on other UNIXes getpwnam() can need a bunch of different files and sockets depending on what nsswitch.conf backend is in use. I guess OpenBSD doesn't support nsswitch at all (it looks like it just uses a pseudo-NIS damon "ypldap" if you want to use LDAP auth) but on most other UNIXes it doesn't work that way.

Similar arguments apply to host resolution, but these days it's almost always just /etc/hosts and DNS so less of an issue.

Agreed - the cognitive load associated with tame is so minimal, that almost everyone gets it, and can use it, immediately.

I don't think I've ever met a casual sysadmin who groks SELinux, and I've never met a user who understands what it's all about.

Something that does 90% of the job that is used 50% of the time, is better than something that does 99% of the job and is used 1% of the time.

tame() isn't for sysadmins or users either - it has to be wired into the application by the application developer.

Exactly. If you isolate this as an programmer's concern then you can skip the administrative effort and assume that the application configures itself properly rather than relies on someone to experiment with producing a sandbox for it to run in. The latter is error prone hence why things like SELinux have permissive and enforcing modes. SELinux turns your job into a reverse engineering one which isn't fun.

I'm slightly bitter that I've become a bit of an SELinux expert over the years. I shouldn't have to be one, hell the tech shouldn't even need to exist in 2015.

The whole idea is that Users and SysAdmins don't have to do anything - it just works. With SELinux, the first thing that users/sysadmins do is disable it because it's screwing up their environment and annoying them.

SELinux isn't that hard. Disabling it is just lazy.

Granted, creating a really secure policy takes effort, but even just having it enabled with simple policies can help mitigate the impact of a bunch of vulnerabilities, even if it won't make you invulnerable.

I spent two days trying to get selinux working with our servers and just gave up again. I have actual work to be done instead of turning the selinux knobs. Something simple as tame would be welcome, zero administrative overhead but plugs few potential security holes.

I can't say what you were trying to do, but I've had to set up SELinux several times, and it's always been a fairly simple iterative process:

1. enable permissive mode

2. test application

3. check audit logs for any complaints

4. if no complaints, you're done. enable enforcing mode and test again.

5. otherwise, evaluate the complaints and fix the issues, either by tuning fcontexts (often, a simple path equivalency is enough if you're installing things on nondefault paths, as is common.) or by creating a custom policy module (audit2allow helps), then go to 2.

It's work you should do anyway. Securing an environment is part of setting it up.

The users/sysadmins I've known take the following process:

o Run Application

o Get weird error.

o Google the error, see someone mentioning "This is because of SElinux"

o Google how to "Disable SELinux"

I'm not saying that's what they should be doing, just saying it's what I've observed. What's nice about tame is - there is nothing to enable/disable, it's just part of software.

That's pretty much the definition of lazy. Yes, its one more thing that needs to be learned but that is part of the job.

> What's nice about tame is - there is nothing to enable/disable, it's just part of software.

And what's nice about SELinux (if you learn it) is it applies to the system and everything running on it whether or not it's been written for it. You can even put it in a logging only, and use those logs to generate the needed policies. SELinux will tell you what is going on.

What you point out as nice about tame() means that nothing will use it except what is in the core of OpenBSD.

Completely agree with you that SELinux is a better general solution, applies to a broader community of software, and that users, and certainly sysadmins, should take the time to understand how it works, generate policies for the software they use, and take advantages of the security that it provides.

Years ago when I was trying to simply grok selinux, I ran into the dontaudit rules. That was very frustrating and hair pulling day. I had and have no problem disabling selinux to this day.

tame is easy and simple, which is a good thing, but comparing it to SELinux for ease of use is missing the point. SELinux is capable of providing very fine-grained access control depending on user, process and file contexts. tame is merely a syscall filter.

It's a good tool for dropping privileges from a process, but it doesn't even attempt to solve the same problem that SELinux does.

You're right but 99% of the problems I end up solving with SELinux are problems that fit tame perfectly. The rest of the problems are architectural i.e. the process doesn't have privilege separation mechanisms etc.

Logical time based "NX", interesting.

Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact