DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 26th April 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,786
Default systrace(1) is removed for OpenBSD 6.0

The systrace() toolkit was a system call policy implementation tool. A policy of allowed syscalls could be devised and applied to a specific application.

In practice, this was difficult to manage universally because the policy implementation was external to the application. Every application change required a review and revision of the permitted system calls. At one time, there was a central repository of user-suggested policies -- called the "Hairy Eyeball Project" -- but each user had to conduct their own audit, and once the project ceased operations (2004? 2005?), users became completely responsible for their own policy development, and usage waned.

In addition, a carefully crafted application could circumvent systrace() policy enforcement, and when that was discovered and published, the use of systrace() as a security tool ended.

OpenBSD continued to keep systrace() available because it was valuable during port development of 3rd party applications. The ports(7) system had a knob, USE_SYSTRACE, which would enable a standard policy for what any port was allowed to do during building of the application and installing into the ports() fake infrastructure. Generally, that policy would prevent the port from writing to any component of the filesystem outside the ports object tree, or opening network sockets during building.

Was. Had. Would. These policies became unneeded once it was possible for unprivileged users to build a port except for the final pkg_add(1) used during the make install step.

OpenBSD's bulk port building tool dpb(1) has a security model that provides granularity of access, simply by using different unprivileged users for different parts of the build. As an example, there can be a BUILD_USER and a FETCH_USER with different authorizations.

Finally, a much simpler and more deployable system call policy management tool has replaced systrace(): pledge(2).

---

The OpenBSD project works hard to remove facilities which aren't being actively used or maintained. Old code that is retained without constant testing can become a security problem. Removal eliminates that risk.

---

The first of many commits: http://marc.info/?l=openbsd-cvs&m=146161167911029&w=2

Last edited by jggimi; 26th April 2016 at 03:41 PM. Reason: added link
Reply With Quote
  #2   (View Single Post)  
Old 26th April 2016
hanzer's Avatar
hanzer hanzer is offline
Real Name: Adam Jensen
just passing through
 
Join Date: Oct 2013
Location: EST USA
Posts: 227
Default Pledge() – a new mitigation mechanism in OpenBSD

Here are the slides and video of Theo's Pledge() presentation at Hackfest 2015.
Reply With Quote
  #3   (View Single Post)  
Old 27th April 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,786
Default

Thanks for posting the pledge() links. I've previously pledged a complex port. That it was possible for me to do so is a clear compliment to the simplicity of pledge().

---

If it seems like I'm in agreement with this decision to remove systrace(), I'm actually ambivalent.

I understand the need to remove it. I can agree with the valid reasons to do so. The Hairy Eyeball Project had been gone for more than a decade, and was only a repository of best guesses. The systrace() tool had been unmaintained except for obvious sustaining engineering requirements. There was a performance impact when using it, as it intervened to monitor every syscall.

I still liked the systrace.policy for ports. I could build new ports as a normal user, and not worry about attacks during build from any possible embedded malware, or from mistakes in build decisions made by application developers. (I never had either happen, but you never know.) I even used it last week for a new port, and it caught a common write to /usr during make fake. But systrace() wasn't truly necessary to catch that. I was building as a normal unprivileged user, and the target would have failed even without systrace(). And now, as I only develop ports on -current, it won't be possible for me to use it any longer.

The dpb(1) man page has a section on its ports build security model. It's interesting, because it describes the separation of authority between the various users that can be deployed. A build user only needs access to a very small set of directory structures. It does not need network connectivity; that's the responsibility of the fetch user. The log user records build logs, so the build user doesn't even need access to those structures. The dpb() model has me thinking how I will manage new port development without systrace().

Last edited by jggimi; 27th April 2016 at 12:36 AM. Reason: clarity
Reply With Quote
  #4   (View Single Post)  
Old 27th April 2016
hanzer's Avatar
hanzer hanzer is offline
Real Name: Adam Jensen
just passing through
 
Join Date: Oct 2013
Location: EST USA
Posts: 227
Default

Pretty much all I know about the Pledge() approach is what I gleaned from Theo's presentation (so, not much). What seems [to me] to be missing is instrumentation, records, analysis, and feedback.

My concern is the reliability of the overall computing system will decrease. Some programs will violate their pledge and be terminated (hasta la vista, baby) because the software is tricky and a specific context might trigger the violation. It seems like some kind of snapshot (black-box) of the circumstances, environment, and state of the terminated program would be needed to determine the source of the problem. Without that, developers might never get a clear view of tricky, transient problems in some programs.
Reply With Quote
  #5   (View Single Post)  
Old 27th April 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,786
Default

Everything you currently consider missing is available. Because I used them all.
  1. The abort from a policy violation produces a .core file. A backtrace will point you immediately to both the failing system call, and to the calling path from the application. This addresses all four of your concerns, and was my key development tool.
  2. A failed pledge() call will take the code path desired by the author. That can be as simple as a call to perror(3), but the pledge author can cause any operation they write. This is instrumentation by definition, and may include one, two or all three of your remaining concerns.
  3. System calls may be traced and monitored with ktrace(1)/kdump(1). Theo has mentioned on misc@ that this is they key tool for pledge() implementation, but I found item 1 above more useful. Probably because for me this is only instrumentation and records, requires separate analysis and doesn't include feedback.
  4. Because the application I pledged has such complex underpinnings, I used my own debug preprocessor tokens during development and testing. And when unexpected code paths were taken and discovered long after testing had completed, they were useful to me again. An example of the added debug token use with pledge can be seen in this patch. This is instrumentation, reporting, and feedback -- three out of four, but permitted me much simpler analysis.
Some applications are not really pledge-able. I just looked at sysutils/shunt, which has three utility programs. The exactly program is easy to pledge. It only needs stdio, and the pledge() can be placed as the first instruction in main(). Tested, works fine. But the shunt program? It issues fork()/execlp() sequences of a user-specified program. These child processes are outside the control of the shunt program. They are typically going to be shell scripts, or direct calls to cdrecord or growisofs. I'm unsure if pledging a program like shunt would add value. It might, because ksh(1) has been pledged. But there are plenty of shells which have not been pledged yet, and neither sysutils/cdrtools nor sysutils/dvd+rw-tools have been pledged to date.

Last edited by jggimi; 27th April 2016 at 10:32 AM. Reason: typos
Reply With Quote
  #6   (View Single Post)  
Old 27th April 2016
hanzer's Avatar
hanzer hanzer is offline
Real Name: Adam Jensen
just passing through
 
Join Date: Oct 2013
Location: EST USA
Posts: 227
Default

Quote:
Originally Posted by jggimi View Post
Everything you currently consider missing is available. Because I used them all.
Supercool. All of this has me somehow thinking of SPARK/Ravenscar Ada. It's probably just sleep deprivation but I'm pondering the delicate differences between [progressive] cybernetic goodness and [stagnate] police state badness.
Reply With Quote
  #7   (View Single Post)  
Old 27th April 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,786
Default

I can't speak to the point. Mostly because I'm heading out the door to $DAYJOB and won't be able to review the video you linked. But having used both systrace() and pledge(), and liking both, I can speak to the key differences in policy authorization.
  • The systrace() toolset is external to the application being monitored and constrained.
  • The pledge() syscall is part of the application. For ports, that's done with OpenBSD-specific patches such as the example above, or may be integrated into the upstream application.
This leads us to Theo's main complaint about external mitigation policy tools of all kinds. They can be disabled, turned off, and removed. A pledge() is a risk mitigation which is integral to the application, and is not optional once deployed.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
OpenBSD Opera will be removed for 5.8 jggimi News 16 26th March 2017 03:35 PM
OpenBSD nginx will be removed from base in OpenBSD-5.7 jggimi News 2 27th August 2014 05:59 PM
OpenSolaris equivalent of systrace? DraconianTimes Solaris 9 31st January 2009 05:36 AM
Systrace Oko OpenBSD Security 1 29th December 2008 01:52 PM
Why Does FreeBSD reboot if USB Drive Is Removed before unmount bsdforlife FreeBSD General 10 2nd September 2008 06:18 AM


All times are GMT. The time now is 11:53 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick