The poisoned NUL byte, 2014 edition (Project Zero)

Posted Aug 27, 2014 5:27 UTC (Wed) by wahern (subscriber, #37304)
In reply to: The poisoned NUL byte, 2014 edition (Project Zero) by spender
Parent article: The poisoned NUL byte, 2014 edition (Project Zero)

This is why Capsicum is a much better long-term model for application security.

The knowledge about what privileges are needed and which can be dropped is _already_ known to the developer of the application.

Systems like SELinux appeal to sysadmins and database administrators, whose hammer is tweaking configuration files. And while that's often useful and necessary, it's no substitute for giving the developer the ability to manipulate privileges at the very places were privileges are used and applied.

The poisoned NUL byte, 2014 edition (Project Zero)

Posted Aug 27, 2014 12:41 UTC (Wed) by raven667 (subscriber, #5198) [Link] (1 responses)

It's not an either/or situation, Capsicum is not the be-all, end-all solution to application security, it only helps with a subset of use cases, and is orthogonal to a permission checker like SELinux. Manipulating privileges from inside your program is great for the code you write yourself, but doesn't help for the vast majority of the code on your system which you didn't write. Specifying your own seccomp syscall filters and SELinux permissions are part of the whole solution as well.

The poisoned NUL byte, 2014 edition (Project Zero)

Posted Aug 27, 2014 17:00 UTC (Wed) by ThinkRob (guest, #64513) [Link]

There are two types of access control questions to answer though:

1) What does this application need to do in order to perform all permutations of <insert functionality here>?

2) What does this application need to do in order to perform its role on <insert system here>?

#1 is what the developers can and should answer. Something like Capsicum is a good tool for them to provide that answer. The author of an image viewing application knows it's never going to need to list on a TCP port for anything, so he can make that declaration via some AC system and close off an entire class of attacks.

#2 is what system administrators answer. Something like SELinux or grsecurity's RBAC is a good tool for them to provide that answer. Some image viewer might allow for you to save a file to disk, but it's up to your system administrator to determine whether that's a "safe" action (and thus whether to categorically prevent it.)

You can generally express the answers to #1 using a tool suited for #2, but that's error prone, tedious, and generally not a good solution.