New "scallhook" feature. Is is OK to create a proposal?
alexanderchuranov at gmail.com
Thu Apr 8 15:42:29 UTC 2010
Robert, Warner, and the mailing list,
Some things need to be clarified:
1) This is NOT a Google Summer of Code project and we are not students.
2) There are NO plans to create a wrapper for system calls. The feature
should be an integral part of the kernel.
3) There are plans to avoid races by design. The feature is to be
implemented into several steps:
* Deal with direct arguments only. This is not hard and easy to get right.
* Deal with indirect arguments of some calls by copying values. When
passing control to the actual syscall, substitute original indirect
arguments with copies.
* Optimize indirect arguments handling by eliminating extra copies and
processing. This is actually hard. It's necessary to mention that this is
not an all-or-nothing project. The goal is to provide actually useful and
safe features. It's expected that some calls may be left unhookable.
4) The quality is to be maintained by using automated unit-tests,
integration tests, stress and capacity testing as well as utilizing working
exploits for system call wrappers.
5) The feature will never provide privilege elevation (unlike systrace).
It's intended to be more like securelevel and ulimit: there will be a single
operation for adding a module to the list of hooks for the process. The
lists, of course are inherited. The application will be unable to examine
We are going to create a page on FreeBSD wiki with details of the proposal:
motivation, comparison to other security features, feature details, test
plan and implementation plan. When the page is finished and before the
implementation, we'd like to gather reviews of the plan. Then the
information about progress will be posted periodically to the lists.
If everything is right with the project, based on the information provided
here, then we are going to proceed with the wiki.
Should we go ahead?
More information about the freebsd-arch