Re: sandboxing untrusted binaries
Niels Provos wrote: > > I suggest getting over the illusion hackers won't be able to hack the > > system if you narrow them a bit, the binaries you run still need > > capabilities to correctly function, which are always enough to hack the > > system. > This is not correct either. There is no illusion here. Please, give > me an example where the capabilities needed "are always enough to hack > the system." Say gaim or opera. Any application whose call subset is still von Neumann complete is capable of being hacked to implement any program, if it is capable of being hacked. Sand-boxing strikes me as a way to close the the hen house with the weasel inside: it doesn't do anything for the chickens. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sandboxing untrusted binaries
On Fri, May 31, 2002 at 02:56:53PM +, [EMAIL PROTECTED] wrote: > Netscape for instance needs to execute other binaries, the user should > be allowed to specify which binaries. Netscape needs to write cache > files, any hacker exploiting netscape can use that to create a new > process which isn't systrace-profiled. This is not correct. I suggest that you look at the systrace web page again and read all the information there. It is very feasible and desirable to run any third-party software under systrace. For example, it is not possible for netscape to create a process that is not monitored. I suggest that you look at the sample konquerer policy. > I suggest getting over the illusion hackers won't be able to hack the > system if you narrow them a bit, the binaries you run still need > capabilities to correctly function, which are always enough to hack the > system. This is not correct either. There is no illusion here. Please, give me an example where the capabilities needed "are always enough to hack the system." Say gaim or opera. > this is very specific for the program, you can't make judgements like > this without being sure for what applications this applies. In reverse, for which application is the assumption that read and write are frequently executed system calls incorrect? Niels. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sandboxing untrusted binaries
On Wed, 29 May 2002, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Bjoern Fischer <[EMAIL PROTECTED]> writes: > : Hello, > : > : OpenBSD has a new interesting feature: systrace. It is a system call > : policy generator for "sandboxing" untrusted or semi-trusted binaries. > : > : The whole idea looks interesting. The implementation details look > : relatively simple (read: not too complicated). Anyone interested in > : having a closer look and maybe porting it? > : > : Or I will try to port it myself if at least one core member says: > : "Interesting technology, send a patch..." > : > : http://www.citi.umich.edu/u/provos/systrace/ > > The SecureBSD folks did something similar to an old version of > FreeBSD, but had such a restrictive license that no one ever > investigated merging it into the mainline. Already sent out some private e-mail, but I figured I'd send it out in public too. First, there's a lot of prior art in this space -- for example, see the generic software wrapper toolkit at ftp://ftp.tislabs.com/pub/wrappers -- although for a somewhat older version of FreeBSD, it allows a language-driven restriction of processes based on system call wrapping. Unfortunately, this software is under a more restrictive license than really desirable, making it less useful, but worth referencing. Likewise, LOMAC in the base tree uses the same wrapping approach, although not to provide a general purpose policy framework. There are a number of reasons we're spending a lot of time on the TrustedBSD MAC framework, and opted not to stick with the system call wrapping approach. They include: - Fine-grained locking. System call "wrappers" that enforce policies only at the ABI and top service layers of the kernel are inherrently subject to race conditions in fine-grained (and even less fine-grained) kernels. This occurs for two reasons: first, time-of-check-time-of-use issues which exist both in both traditional and newer kernel models. These frequently exist when arguments are pulled into the kernel multiple times, because a deeper layer of the kernel pulls in the string from userland, so the wrapper also pulls the string in. Through careful manipulation, the attacker can force the wrapped security check to occur on a different object than the actual request. Second, as you move towards higher parallelism in the kernel, these problems get dramatically worse. Consider process locking. If the wrapping policy and the base kernel both require locks on a target process to perform their checks, and the base kernel assumes it doesn't hold the lock, the wrapping code has to release the lock before the "real" code can execute providing the service. If parallelism is present, then the protections on the process could easily change while the lock isn't held, resulting in a time-of-check/time-of-use vulnerability. The process case would require a lot of hard work to implement, but the vnode case is a lot easier to exploit, as there are frequently long periods of blocking associated with VFS operations, opening up race windows. - Object aliasing issues. Often, you can logically think about the kernel as providing access to a series of objects and services. There are a series of service components of the kernel that maintain the objects, and objects are usually the granularity of access control (i.e., individual objects have individual protections, and classes of objects sometimes share a single set of protections). Unfortunately (or fortunately if you're an application writer), the kernel can offer many ways to name the same object -- pathnames, file descriptors, etc. These names tend to change a lot over time, and often objects have multiple names even in the same namespace. This puts system call wrappers in a very bad place to consistently enforce policies -- what they'd like to do is enforce policies based on the object, and not based on the name. Unfortunately, the authoritative name->object conversion is sometimes done deep in the kernel, resulting in race conditions as described in the previous paragraph. Especially for synthetic filesystems, it may be almost impossible for a wrapper to determine what a name will point to by the time it gets evaluated by the real kernel code. With additional ABI's thrown into the mix, the complexity can get very high. - Consistent policy expression issues. Most system call wrapping tools have a hard time expressing consistent policies when the policies are highly complex. Consider the following class of policies: there are two classes of processes, high integrity and low integrity. Likewise, there are two classes of objects, high integrity and low integrity. Permit low integrity processes to read from objects of either type, but write only to low integrity objects. Permit high integrity processes to write to objects of either type, but read only
Re: sandboxing untrusted binaries
On Fri, May 31, 2002 at 12:50:59PM +0200, Bjoern Fischer wrote: > > The second group is more for trying to keep hackers from gaining local > > access. The examples provided by systrace are for this group of > > programs. But, the same concept applies: the binary needs to run local > > and access local files and even write to files. A webbrowser still needs > > to execute xpdf, the user still needs to be able to specify what program > > to run for pdf's. You can limit the possibilities, but, the minimal > > capabilities a program needs to function is always enough for a hacker. > > I think you are wrong here. If there are normal user applications that > let local users compromise the system, the operating system is flawed. > And even if there is any, users who attempt to compromise the system, > or who behave grossly negligent regarding system security, are candidates > for rmuser(8) anyway. > > The target of systrace is not the local user (or unwelcomed "visitor" > disguised as a local user) who attempts to hack the system. This > will never work, since you always can install a not-sandboxed > version of the affected software with normal user privileges. > > systrace is not for sandboxing users but for sandboxing untrusted > binaries. Such as netscape for example. Of course you never would > run netscape as root. But you may even consider your "normal" user > privileges as too powerful (reading PGP-Keys, tampering .rhosts or > xauth, deleting you reports). You miss the point here. Lets say you are a user on a box and you run netscape. Lets say there is a bug in netscape, netscape could be considered untrusted, and evil hackers can exploit your netscape when you browse their site. This is completely the same issue as for setuid binaries, netscape needs local capabilities which are always enough for hackers to hack the system. It is an illusion to think that making hackers not being able to read the PGP-Keys are unable to hack the system. Netscape for instance needs to execute other binaries, the user should be allowed to specify which binaries. Netscape needs to write cache files, any hacker exploiting netscape can use that to create a new process which isn't systrace-profiled. I suggest getting over the illusion hackers won't be able to hack the system if you narrow them a bit, the binaries you run still need capabilities to correctly function, which are always enough to hack the system. (I ment remote hackers exploiting your bitchx and netscape, not local users) > > I have coded similar things for linux, the main problem is the > > performance hit. For every system call, you will need to check against > > the policy and systrace even provides regular expression filters etc. > > I don't expect a greater performance hit than ktrace. Far most system > calls are read() and write() anyway. this is very specific for the program, you can't make judgements like this without being sure for what applications this applies. Frank van Vliet To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sandboxing untrusted binaries
At 12:50 31/05/2002 +0200, Bjoern Fischer wrote: >systrace is not for sandboxing users but for sandboxing untrusted >binaries. Such as netscape for example. Of course you never would >run netscape as root. But you may even consider your "normal" user >privileges as too powerful (reading PGP-Keys, tampering .rhosts or >xauth, deleting you reports). I think even more useful than sandboxing netscape would be sandboxing netscape (or other application) plugins. I'd certainly be much more willing to download and run the foo-reader plugin from 31337 enterprises if I knew that it would be unable to make any system calls beyond those necessary to interface with the owning application. Colin Percival To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sandboxing untrusted binaries
Hi Frank, > The idea of sandboxing binaries is nice ofcourse but there is a > conceptual drawback. > > I think you can divide the programs you run in two groups: > > the group of extra privileged programs which need that for changing > passwords or for allowing users to log into their shell (ssh etc). These type of programs are not the target of systrace. Normally you have the sources for programs that need raised privileges, so these programs can be trusted. If you expect security risks when you set up larger applications that partially need root privileges, you probably want to use jail(8) or capabilities (FreeBSD-5?). > The second group is more for trying to keep hackers from gaining local > access. The examples provided by systrace are for this group of > programs. But, the same concept applies: the binary needs to run local > and access local files and even write to files. A webbrowser still needs > to execute xpdf, the user still needs to be able to specify what program > to run for pdf's. You can limit the possibilities, but, the minimal > capabilities a program needs to function is always enough for a hacker. I think you are wrong here. If there are normal user applications that let local users compromise the system, the operating system is flawed. And even if there is any, users who attempt to compromise the system, or who behave grossly negligent regarding system security, are candidates for rmuser(8) anyway. The target of systrace is not the local user (or unwelcomed "visitor" disguised as a local user) who attempts to hack the system. This will never work, since you always can install a not-sandboxed version of the affected software with normal user privileges. systrace is not for sandboxing users but for sandboxing untrusted binaries. Such as netscape for example. Of course you never would run netscape as root. But you may even consider your "normal" user privileges as too powerful (reading PGP-Keys, tampering .rhosts or xauth, deleting you reports). > I have coded similar things for linux, the main problem is the > performance hit. For every system call, you will need to check against > the policy and systrace even provides regular expression filters etc. I don't expect a greater performance hit than ktrace. Far most system calls are read() and write() anyway. Björn Fischer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sandboxing untrusted binaries
Hi Bjoern, On Thu, May 30, 2002 at 04:58:18AM +0200, Bjoern Fischer wrote: > OpenBSD has a new interesting feature: systrace. It is a system call > policy generator for "sandboxing" untrusted or semi-trusted binaries. The idea of sandboxing binaries is nice ofcourse but there is a conceptual drawback. I think you can divide the programs you run in two groups: the group of extra privileged programs which need that for changing passwords or for allowing users to log into their shell (ssh etc). the group of normal programs ran by a user interacting with the outside world like a browser. The problem is, a program needs privileges in order to perform its function. if this function is to change passwords, it needs privileges to actually change those passwords. The same thing goes for capabilities: you can finetune exactly what is allowed, but the main thing a program is supposed to do will still be allowed. If that program was ment to do something which requires root, and you disable everything else so the program can only do that little thing like changing passwords, an attacker gaining control of the process will still be able to do enough to hack the box. You can make it harder for him, but if the binary had to run with root privileges, and you disable all other privileges, an exploiter can still hack the box. If you could drop all privileges, the binary shouldn't be ran as root in the first place. This all goes for the first group of programs i just mentioned. The second group is more for trying to keep hackers from gaining local access. The examples provided by systrace are for this group of programs. But, the same concept applies: the binary needs to run local and access local files and even write to files. A webbrowser still needs to execute xpdf, the user still needs to be able to specify what program to run for pdf's. You can limit the possibilities, but, the minimal capabilities a program needs to function is always enough for a hacker. > The whole idea looks interesting. The implementation details look > relatively simple (read: not too complicated). Anyone interested in > having a closer look and maybe porting it? I have coded similar things for linux, the main problem is the performance hit. For every system call, you will need to check against the policy and systrace even provides regular expression filters etc. This is a major performance hit for most daemons. > Or I will try to port it myself if at least one core member says: > "Interesting technology, send a patch..." I'm not sure if the performance hit will be worth the limiting of possibilities for hackers. They will still get in, it will only take a more specialized shellcode. Looking forward for others' views, Frank van Vliet [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sandboxing untrusted binaries
On Thu, 30 May 2002, Bjoern Fischer wrote: > Hello, > > OpenBSD has a new interesting feature: systrace. It is a system call > policy generator for "sandboxing" untrusted or semi-trusted binaries. > > The whole idea looks interesting. The implementation details look > relatively simple (read: not too complicated). Anyone interested in > having a closer look and maybe porting it? > > Or I will try to port it myself if at least one core member says: > "Interesting technology, send a patch..." > > http://www.citi.umich.edu/u/provos/systrace/ > > Björn Fischer You might want to talk to Robert Watson and see if the concept overlaps or conflicts with anything he's doing as part of the TrustedBSD project. As long as systrace does not conflict with what he's doing and does not introduce the possibility of new security holes, I'm suspect that a port of the code would not meet much resistance. Go for it! Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sandboxing untrusted binaries
In message: <[EMAIL PROTECTED]> Bjoern Fischer <[EMAIL PROTECTED]> writes: : Hello, : : OpenBSD has a new interesting feature: systrace. It is a system call : policy generator for "sandboxing" untrusted or semi-trusted binaries. : : The whole idea looks interesting. The implementation details look : relatively simple (read: not too complicated). Anyone interested in : having a closer look and maybe porting it? : : Or I will try to port it myself if at least one core member says: : "Interesting technology, send a patch..." : : http://www.citi.umich.edu/u/provos/systrace/ The SecureBSD folks did something similar to an old version of FreeBSD, but had such a restrictive license that no one ever investigated merging it into the mainline. Way cool idea. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
sandboxing untrusted binaries
Hello, OpenBSD has a new interesting feature: systrace. It is a system call policy generator for "sandboxing" untrusted or semi-trusted binaries. The whole idea looks interesting. The implementation details look relatively simple (read: not too complicated). Anyone interested in having a closer look and maybe porting it? Or I will try to port it myself if at least one core member says: "Interesting technology, send a patch..." http://www.citi.umich.edu/u/provos/systrace/ Björn Fischer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
