flowpriv

concept
implementation
supported operating systems
peer review and contributions
programming notes and questions
obstacles

the concept

Currently, root is the only user that can actually drop significant privileges, as root is the only user that has access to such functions. This is flawed. The idea behind the flowpriv modification is that any user should be able to relinquish its abilities. Socket operations, filesystem operations, signals and program execution should not be required process functionality unless the process itself requires it to function.

This is different from "capabilities" because it does not deal with elevated privileges. Files are never given specific privileges, but may only drop those that are by default bestowed upon them. Additionally, "capabilities" do not offer the sort of privilege resignation that flowpriv does.

It's also different from systrace in that it does not burden the system administrator, but the programmer. Programmers may modify their software to drop privileges when they are no longer needed, and they may design their programs to use restricted environments more effectively. Just as some programmers use chroot(2) and setuid(2) services, so may they use this privilege interface. This enables a program to lean further towards the idea of "secure by default", rather than "secure by much learned effort".

implementation

A new kernel function must be added for user interface, and the necessary stubs must be added to the standard C library. The design of this interface will likely be the most difficult part of implementing flowpriv.

Other modifications (i.e. privilege checks) will be added to individual functions, requiring that this be a patch, not a module. The reasoning here is as follows.

Firstly, simple variable checks within each function will execute faster than calling a separate function and passing the necessary data. All local variables are readily available as necessary; if one wishes to block writable open calls, there need not be a specialized argument for passing function call flags (which would then need to be cast to a function-specific structure). Doing so would add unnecessary complexity and waste cpu cycles. Inline privilege checking should yield an extremely small performance footprint.

Secondly, offering this as a module would be counterproductive. Programmers will be less likely to adopt and use this new interface, and it would never become widespread. If it goes unused, none are worse; if it's used effectively, everyone benefits. That's not to say it shouldn't be a compile-time option, but i believe the compile-time option should be something akin to "options NOFLOWPRIV" instead of "options FLOWPRIV".

supported operating systems

Initially, i plan to write a modification for freebsd. If this goes over favorably, i will then port this modification to linux, and likely other bsd systems as well. For this effort to be realized, support must be widespread and uniform enough (at least in the C library interface) to offer some semblance of portability.

peer review and contributions

This, as a security-related modification of kernel functionality, is obviously an area that will need significant peer review, in both design and implementation. All feedback is most welcome. There is a mailing list for this project, to which you may subscribe by sending an empty message to flowpriv-subscribe@episec.com. Archives are available.

There is a proof-of-concept patch available here. This patch is for the FreeBSD 5.1-RELEASE-p2 kernel, which is currently available via CVSup as RELENG_5_1. In this patch, the creation of regular files is restricted.

Any statement of design herein may be challenged. Nothing is yet static.

programming notes and questions

Privilege additions to the proc structure will be present within every process on the system. The smaller the memory footprint, the better. Function flags should be bits, not characters or integers. The resultant increase in proc structure size is estimated at approximately four bytes.
The interface should be based on classification, not functions. Kernel functions are not portable; classifications are. An example of a classification would be the equivalent of "drop mode-changing permissions", potentially affecting chmod, chflags, fchflags, and fchmod.
How granular should classifications be? [e.g. "drop mode-changing permissions for files that are not currently open", affecting chmod and chflags, but not fchmod or fchflags.]
Should functions that are only accessible to root be included? This would be useful if, say, a process needed to keep root privileges for some reason, but wanted to relinquish certain tasks. Similar functionality is already covered with "capabilities", but including it here would create a uniform interface.
Currently, the plan is to patch 5.1-CURRENT. However, patching 5.1-RELEASE would enable a number of users to keep a synchronized kernel version somewhat more easily, so that patch testing can work more smoothly. The nature of this patch would allow later porting to the -CURRENT branch relatively painlessly. For these reasons, working against 5.1-RELEASE may be more desirable.
While i have already made a number of preliminary design decisions, i have not yet put them all on tap. They will be discussed on the flowpriv mailing list, and will be added subsequently.

obstacles

There are many ways to perform each task. As freebsd is updated, more kernel functions find their way in. These must be taken into account as time goes on.

ari edelkind - [contact]