Systrace for Mac OS X

Niels Provos writes in that he has added Mac OS X support for Systrace, a sandboxing/application confinement tool that can be used to increase application and service security. It installs a new kernel to support /dev/systrace and the Systrace application, and a Cocoa frontend.

Comments

Replace my kernel?, but I like my kernel

[Kplusplus]

My only qualm is where is this kernel coming from and why is there no other way to run this then with a specially built kernel. Im sorry to say, but I can't just trust anything that replaces my kernel, no matter who it comes from when that person isn't my OS vendor.

Is it impossible to get teh same thing done with a kernel extension?

Re:Replace my kernel?, but I like my kernel

[LizardKing]

My only qualm is where is this kernel coming from and why is there no other way to run this then with a specially built kernel

The patch is there for you to peruse, along with the Darwin kernel source. So if your feeling a little paranoid then go for it. As to why this couldn't be a module of some sort, does the Darwin version of the BSD kernel support lkm's? And even if it does, systrace operates at a much lower level than say a device driver (which is where kernel modules really come into their own).

Chris

Re:Replace my kernel?, but I like my kernel

[Anonymous Coward]

I see no reason it couldn't be a KEXT, other then if you are apt to run this type of util,
it's not exactly something that you would choose to load or unload depending on your mood.

It works well, I've run it on OpenBSD (where it made it's initial appearance) for many months. If you are in a mode where you are preventing elicit use of syscalls such as a typical exploit execve'ing a copy of /bin/sh, i doubt you would want to remove this functionality that is protecting you from such methods.

In lieu of the fact there are is no stack/heap protection in OSX... You might want to give it a try... OSX has a long way to go in the security arena. If you can't countermeasure the vulnerable code without retroactive fixes, perhaps you can avoid many common methods in existing shellcode at syscall level.

However, the inclusion of strl* and arc4random is nice to see :)

Kernel vendors

[m0rph3us0]

Yeah, because if your vendor made it then it must be secure.....

Why not just take a look at the source... its more readily available than the source for Mac OS X.

Re:Kernel vendors

[Anonymous Coward]

Does Apple add anything proprietary to the kernel?

Re:Kernel vendors

[Kplusplus]

Yeah, because if your vendor made it then it must be secure.....

Unlike MS, Apple doesn't make inferior products that have new security holes to be discovered every week. So I really have no reason not to trust Apple's stuff.

As to the source of Mac OS X: Why do you need it? Thier source being open will in no way help Mac OS X, perhaps it may help other *nix distros but not Apple's since they are heavily optimized regularly and provide a layer of operability higher than those of say systrace.

Re:Kernel vendors

[jimmu]

http://www.opensource.apple.com/projects/darwin/6. 0/projects.html

What's this? why, it looks like links to download the source for darwin. And whats that? why, it appears that you can peruse just about everything, save for Quartz.

Note the obfuscated URL. truly, apple is going to great links to hide the source for OS X.

I won't even mention the CVS server.

Re:Kernel vendors

[m0rph3us0]

Yes, apple has never made inferior products, sort of like Mac OS 9 which had no support for virtual memory (i dont mean a swap file btw) and about as much support for users as DOS. Apple does make products that suck and do have security flaws. How about being able to login to a default OS X machine with out being prompted for a password. Personally I think that SUCKS and it is definately a SECURITY FLAW. Software Update is another example of Apple products with security flaws. Having the source available means finding security flaws sooner rather than later. The faster vulnerabilities are found and patched the less exposure your system recieves to them. How do I know that no where strcpy() or a similarly known insecure function is being used inappropriately in the source for their APIs.

Re:Kernel vendors

[Kplusplus]

First of all though you may not like 9 it was much more powerful and its VM system was much better than Windows up until it reached 2000.

Secondly That is not a security flaw, it is a feature. On a single user machine with no guest or other users why should a user ever be prompted to login? To install anyything system level, yes, but to login? You may not see the usefullness of such a thing being that you are used to an OS that no matter which distro was designed as a server OS to be used in workgroup environments. Mac OS X was not it was designed to be in the home.

Software Update is without flaw, every update is crytographically sealed for the exact reason of a possible security flaw or a spoofed apple server, and it only allows updates from the Apple servers. Read the arstechnica article on Software Update for further information on how the new Software Update works. Software Update is much more secure than say apt-get.

Lastly Apple has never had a security flaw and thoroughly checks thier code before it ever gets released. Apple is spends a huge amount of time code auditing, and why you seem to think that you or someone else could do better to find flaws in things you neither wrote nor know how are supposed to work is overly pompous. This isn't the land of linux and windows where buffer overflows run amok. You would be hard pressed to find an example of a product written by Apple that had a security flaw.

Re:Kernel vendors

[Anonymous Coward]

As to the source of Mac OS X: Why do you need it? Thier source being open will in no way help Mac OS X

Right, because third party developers certainly wouldn't add to the source and improve the OS any... Oh wait. No. You're stupid.

Re:Kernel vendors

[Anonymous Coward]

why, it appears that you can peruse just about everything

actually, it appears that I can...

Please Register

The information you requested requires a valid APSL registration (Apple Public Source License).

To proceed to the registration page, click here.

If you have forgotten your password, you may find the Account Assistance page helpful.
Database Change Notice

On Tuesday October 8, 2002, the registration database was upgraded to include e-mail validation. This requires people who were previously registered to fill out the registration form for the new database. We apologize for the inconvenience that this causes.

Apple Source: Free as in NYTimes.com

Proprietary

[mnmn]

I dont think a big momentum will develop in the opensource community to develop for MacOSX. Its just too proprietary. Most developers aiming for MacOSX will use portable API like BSD sockets and QT GUI. The only testing done on MacOSX will be done by people actualy owning iMacs. Would be nice if darwin was released in a more open way to court more developers here. Hear that apple? Give us MacOSX sources and we'll give you the world :)

Profit!

Re:Proprietary

[Gropo]

Eh? Think about the volume of 5+ hour battery-life portables currently on the desks and laps of OSS phreaks... You don't think they have any motivation to port apps over?

Fink's Package DB indicates that the 'big momentum' has already begun...

Re:Proprietary

[pudge]

Would be nice if darwin was released in a more open way

Yeah, because having the entire Darwin sources available under an Open Source license is just ... not open ... enough. Yeah.

Re:Proprietary

[frankie]

Would be nice if darwin was released in a more open way to court more developers

Umm... you mean, like this?

Re:Proprietary

[mnmn]

I meant OSX. sorry.

Re:Proprietary

[Anonymous Coward]

1) Make the Best OS Money Can Buy
2) Open source the whole damn thing.
3) ??????
4) PROFIT!!!

I don't think so. Just about the entire OS is already opensourced. The work done on the quartz engine will reap benefits seen for the next 5-10 years. You can have your opensourced XFree crapola.

hows this differ from UML

[hfastedge]

you can set up something far far more powerful than a chroot'ed area with user-mode-linux

So if anyone is knowlegdeable about the apple part, could you compare the two.

Set restrictions on a system call level

[Brian Hatch]

UML creates a new complete kernel running inside your machine, with it's own /sbin/init process, and the whole schebang. If you want to have apache in here, that's possible, you just need to copy all it's files into the UML's filesystem, set up your host machine to relay the packets in, and other similar setup. Takes a while, but totally doable.

Systrace on the other hand lives inside your normal kernel - you don't run any virtual machines at all. However systrace can decide what system calls a program can use, and if desired limit how they can be called. For example you could say Apache is allowed to create a bound socket to port 80, but no other port. You can say allow it to read files in /var/www/htdocs but nothing else. This means that should some user make a symlink to /etc/passwd, it can't be read. Should someone get Apache to run shellcode, it can't run /bin/sh or open a new network socket for inbound access.

The configuration to do this is rather extensive, but anything that will be expicit must be. See the sample apache config for example.

Systrace works similarly to other kernel hardening patches, such as GRSecurity or LIDS. LIDS for example can lock down access to the filesystem (read/write/nada) and to root permissions (allow root to read non-root files, dissallow socket binding, etc) but this is different in that the systemcalls themselves have been hooked, not just some common access methods.

system call tracing needs to become standard

[g4dget]

On a somewhat related note, I think it is stupid that Apple ships kernels without support for system call tracing tools like "strace" or "truss". System call tracing should be part of the standard install of OS X; it is particularly important on non-development machines. (How is this related? It sounds to me like you could use systrace to implement strace, and (less efficiently) vice versa.)

In any case, I thought that one of the promises of Mach was that these kinds of changes should be doable via plug-ins, without creating a new kernel. Why does this require a "new kernel"?

Re:system call tracing needs to become standard

[Rich_Morin]

I would very much like to see OSX ship with truss; in particular, I would like it to be the Solaris-style truss that can trace descendents of processes, etc. (The FreeBSD version is only a pale shadow of this.) Anyone who agrees with this wish might want to send a note to devbugs@apple.com, supporting Problem ID #3121601.