It's a real struggle between the typical programmer's desire to loosely specify what they want in quick-and-dirty code, vs the operating system's desire to enforce this moving "security" target we keep talking about. And all sandwiched around the limitations of current hardware. Researchers wanting to play in the hardware space have it tough as well; the hardware/software co-design needed (to hack the FPGA breadboards together, get kernels booting, figure out why the VHDL compiler is segfaulting on valid code, user-space gcc hacks to emit new instructions, etc) are pretty demanding.
There's been huge amount of work on the rigorous software theory side in the last few decades, which eliminates the need for hardware to dynamically enforce things that can be statically proven away. Peter Sewell and his team recently successfully formally specified the socket API and machine-proved it. Projects like Microsoft's Singularity, or Cornell's Typed Assembly Language are looking at making practical, high-performance type-safe operating systems. I'd expect that, in the next few years at least, we'll see one of these approaches come to fruition before fine-grained hardware enforcement. And as a long-term goal, isn't it more desirable to have higher quality software than more paranoid hardware?
The guards pages are only practical for larger allocations due to hardware limitations, as you say. Strings are protected by different means such as Propolice; in order to minimise the overhead of Propolice, it "detects" strings (as opposed to byte buffers) and specifically protects them with canaries to try and find overflows that would smash the stack (the local variable re-arrangement tries to put these buffers as close to the canary as it can at compile time). The string detection is a heuristic as gcc doesn't maintain quite enough type information when it reaches the code generation parts which Propolice touches. Also, there is a simple bounds checker built into gcc which looks for incorrect use of statically allocated buffers with some standard functions such as strncpy or sscanf (you'd be amazed how many people specify the buffer size wrong to a bounded function).
None of these are perfect of course, but each of the techniques has found bugs (hundreds in the case of the two mentioned above) in our source and ports trees. It's also great to see projects like CCured being developed at Berkeley; although the overhead is just slightly too high to be used "out of the box" right now, it still works great with select applications such as Apache. The underlying tool, CIL can compile most of the OpenBSD source tree (including the kernel) now, and the result even boots when using a null source-to-source transform.
I don't think the BSD allocator will reveal more software bugs unless the programmers have not tested with Electric Fence.
The OpenBSD allocator already has revealed a number of software bugs (in X11, in ports, they lurk everywhere). Some of the bugs found were years old. Thats the point of the testing process in the OpenBSD release cycle.
I think you're missing the point behind the integration of these technologies into OpenBSD. The idea is that they are always on, with a performance hit that is acceptable that your day-to-day programs can be protected, and most crucially, used under them. Not sitting in a debug environment getting limited regressions and unit tests that the particular programmer felt like writing (and if I want that, I run it under Valgrind, which has a near-miraculous tendency to find lurking bugs).
And considering them in isolation is also dangerous. When you combine the address randomization, W^X, heap protection, propolice canaries and local variable re-ordering, you're left with a system that has accepted a reasonable performance hit in return for a large amount of protection against badly written code. Sprinkle in regular audits, timely releases every 6 months to keep our users up-to-date on stable systems, and a 'grep culture' to hunt down related bugs in the source tree when a bug does strike.
As others have pointed out, other "hero projects" have stuck bits and bobs into their respective distributions. But how many have had the discipline to follow through, maintain and integrate their patches, test the fallout and release a complete OS with thousands of third-party packages year after year... probably only Microsoft, but the first thing they do at the sign of incompatibility is to turn the protection off. Oh well:)
Tsk, you added an "existing" where there shouldn't have been one.
There are various levels of paranoia you can aim for when performing a code sweep, depending on your gcc compiler options (-Wall -Wsign-compare -Wshadow). So we tend to do it in stages so that we can look at chunks of code rather than huge unparsable diffs that will let bugs sneak through (there were a number of integer warnings slowly fixed in earlier releases, but Damien went through and cleaned up all the remaining ones for this release).
The atomicio change is definitely proactive, as we updated its API to be safe with respect to signed/unsigned comparisons. The old atomicio would return a -1 on error (ssize_t), as it was designed to provide a close match to the normal read/write calls. However, if there is no error, then the result has to be cast to an unsigned int (size_t), as the size of the buffer passed could possibly be larger than the value that a signed integer could hold. You can see the potential for confusion there...
Now, the new atomicio is much simpler. It always returns a size_t, and 0 is used to indicate an error. Because 0 is also used to show EOF, we simply use the errno variable to detect that (by setting it to EPIPE).
A typical use is now:
if (atomicio(read,..., len) != len) err(1,"read");
which is nice and easy to read. These integer bugs are tedious and hard to spot; a very dangerous combination in open source software as it means only the bad guys tend to look for them:)
You're right, they are left over equipment from AT&T Labs Cambridge, which were redeployed in the Laboratory for Communication Engineering at the University of Cambridge.
But they're more than prototypes, the phones work really well even six years after being built (mainly due to their thin-client architecture, as only the servers need to be upgraded to run more complex services, not the edge phone hardware).
It's a bit of a shock to see this randomly show up on Slashdot, but for those interested readers, here's a WIP paper about what we're doing with them these days (using the Active Bat location system to migrate mobile phone calls via Bluetooth to the nearest environmental phone among other things). As I said, the paper is very much WIP, and is being hacked up after being freshly rejected from a conference so the link is liable to disappear:-) Feel free to get in touch with the main man behind the phones, Rip Soham, if you are interested in more details (contact details in the link).
As far as I know, no commercially available VoIP phone uses VNC these days, which is a real pity as its a really neat way to offer easily upgradable services to the end user (forget running mobile code on the edge device, compute power is cheap these days).
Re:"Linux" IS secure by default
on
OpenBSD 3.6 Live
·
· Score: 3, Informative
If I combine the core teams, even the security teams of all the flavors COMBINED, we'll have a hard time finding programmers with stable jobs, let alone an advanced degree in the area or an industrial lab support.
Are you serious? Here's a hint... BSD has "Berkelely" in the name, and the university heritage lives on.
Pick and Drop is very cool... in case anyone is interested, we knocked up an audio-based pick and drop interface a couple of years ago inspired by Rekimoto's work. Cheesy videos and webpage available here, and the academic paper describing the work in more detail.
The idea is that you can use existing devices (like voice recorders, mobile phones, PDAs) that can play or record audio to capture documents and move them around. By playing the sound back to a device (e.g. a print server), it decodes the identifer and downloads it via the higher bandwidth network.
I can only say that it's pretty obvious that wasn't my intention... if it had occurred to me that this "astroturfing" was a problem, I could have submitted the story anonymously, or used a friend's account, or a hundred other ways to do it properly.
You might think it's clever to post my home address and phone number to/. by "cunning" use of the 'whois' command, but really - it isn't.
Err, no... the camera does all of the image processing, so there is no GPRS or MMS stuff going on.
The idea is that you interact with local interfaces with low-latency (comms over Bluetooth, fast and free), and when/if you want to buy something, you can just go online and pay via your phone bill without having to whip out credit card numbers etc.
Give me a break... where do the disclaimers stop? I mean, the software's being given away for free for non-commercial use, and I think it's of interest to other techies. Notice I didn't submit anonymously.
And don't start spouting "open-source this, open-source that" to me... I domybitthereaswell. But noone cares about that stuff, so why bother talking about it instead of stuff I think is fun?
You're probably posting from the US. In Europe, it's almost impossible to buy a cellphone without a camera these days. You're correct in that I dont particularly want to take pictures with the crappy camera - so why not use it for something useful?
Will this all run within my 2 second attention span?
Pretty much... the decoding happens in real-time (you see the camera viewfinder, and it highlights tags). Once the main slashdotting dies down, the videos hopefully explain it a bit better.
Not to mention what this would do to the phone's battery life.
Actually, it's not too bad... I was demonstrating this stuff at a research demo day recently, and we ran a normal Nokia 3650 for a good 8 hours without seriously killing the batteries - that the camera and bluetooth active at the same time.
Since the main site is predictably a bit bogged down, there is also a page at the University of Cambridge Systems Research Group detailing the research side of things. It also has some cool videos:-)
OpenBSD has FLAVOR and MULTI_PACKAGES exactly for this. Each port has a set of knobs that can be twiddled, and the binary packages are generated and named appropriately.
Re:DirectFB Inherently Insecure?
on
Qt On DirectFB
·
· Score: 2, Informative
In OpenBSD, Matthieu Herrb patched XFree86 to use privilege separation so that the main X process can drop root privileges and run as a normal _x11 user. The privileged portion just grants it the ability to open devices it needs and send certain signals.
There's no reason why these guys couldn't do the same if they care about security... it's not hard, just requires the OS to support descriptor passing.
The OpenBSD Apache chroot()s after its been run, so it loads all the libraries and modules as normal; no need for fancy mounts or copying libraries into the chroot.
Note that THERE ARE dependencies that should be taken care of before building a new kernel, even on -stable.
No, no, no - propolice has only been added into the -current tree, so if you are tracking -stable, continue as before. Only critical fixes go into -stable, certainly nothing as huge as a big GCC patch.
Slashdot Mirror
It's a real struggle between the typical programmer's desire to loosely specify what they want in quick-and-dirty code, vs the operating system's desire to enforce this moving "security" target we keep talking about. And all sandwiched around the limitations of current hardware. Researchers wanting to play in the hardware space have it tough as well; the hardware/software co-design needed (to hack the FPGA breadboards together, get kernels booting, figure out why the VHDL compiler is segfaulting on valid code, user-space gcc hacks to emit new instructions, etc) are pretty demanding.
There's been huge amount of work on the rigorous software theory side in the last few decades, which eliminates the need for hardware to dynamically enforce things that can be statically proven away. Peter Sewell and his team recently successfully formally specified the socket API and machine-proved it. Projects like Microsoft's Singularity, or Cornell's Typed Assembly Language are looking at making practical, high-performance type-safe operating systems. I'd expect that, in the next few years at least, we'll see one of these approaches come to fruition before fine-grained hardware enforcement. And as a long-term goal, isn't it more desirable to have higher quality software than more paranoid hardware?
The guards pages are only practical for larger allocations due to hardware limitations, as you say. Strings are protected by different means such as Propolice; in order to minimise the overhead of Propolice, it "detects" strings (as opposed to byte buffers) and specifically protects them with canaries to try and find overflows that would smash the stack (the local variable re-arrangement tries to put these buffers as close to the canary as it can at compile time). The string detection is a heuristic as gcc doesn't maintain quite enough type information when it reaches the code generation parts which Propolice touches. Also, there is a simple bounds checker built into gcc which looks for incorrect use of statically allocated buffers with some standard functions such as strncpy or sscanf (you'd be amazed how many people specify the buffer size wrong to a bounded function).
None of these are perfect of course, but each of the techniques has found bugs (hundreds in the case of the two mentioned above) in our source and ports trees. It's also great to see projects like CCured being developed at Berkeley; although the overhead is just slightly too high to be used "out of the box" right now, it still works great with select applications such as Apache. The underlying tool, CIL can compile most of the OpenBSD source tree (including the kernel) now, and the result even boots when using a null source-to-source transform.
I don't think the BSD allocator will reveal more software bugs unless the programmers have not tested with Electric Fence.
:)
The OpenBSD allocator already has revealed a number of software bugs (in X11, in ports, they lurk everywhere). Some of the bugs found were years old. Thats the point of the testing process in the OpenBSD release cycle.
I think you're missing the point behind the integration of these technologies into OpenBSD. The idea is that they are always on, with a performance hit that is acceptable that your day-to-day programs can be protected, and most crucially, used under them. Not sitting in a debug environment getting limited regressions and unit tests that the particular programmer felt like writing (and if I want that, I run it under Valgrind, which has a near-miraculous tendency to find lurking bugs).
And considering them in isolation is also dangerous. When you combine the address randomization, W^X, heap protection, propolice canaries and local variable re-ordering, you're left with a system that has accepted a reasonable performance hit in return for a large amount of protection against badly written code. Sprinkle in regular audits, timely releases every 6 months to keep our users up-to-date on stable systems, and a 'grep culture' to hunt down related bugs in the source tree when a bug does strike.
As others have pointed out, other "hero projects" have stuck bits and bobs into their respective distributions. But how many have had the discipline to follow through, maintain and integrate their patches, test the fallout and release a complete OS with thousands of third-party packages year after year... probably only Microsoft, but the first thing they do at the sign of incompatibility is to turn the protection off. Oh well
Tsk, you added an "existing" where there shouldn't have been one.
..., len) != len) err(1,"read");
:)
There are various levels of paranoia you can aim for when performing a code sweep, depending on your gcc compiler options (-Wall -Wsign-compare -Wshadow). So we tend to do it in stages so that we can look at chunks of code rather than huge unparsable diffs that will let bugs sneak through (there were a number of integer warnings slowly fixed in earlier releases, but Damien went through and cleaned up all the remaining ones for this release).
The atomicio change is definitely proactive, as we updated its API to be safe with respect to signed/unsigned comparisons. The old atomicio would return a -1 on error (ssize_t), as it was designed to provide a close match to the normal read/write calls. However, if there is no error, then the result has to be cast to an unsigned int (size_t), as the size of the buffer passed could possibly be larger than the value that a signed integer could hold. You can see the potential for confusion there...
Now, the new atomicio is much simpler. It always returns a size_t, and 0 is used to indicate an error. Because 0 is also used to show EOF, we simply use the errno variable to detect that (by setting it to EPIPE).
A typical use is now:
if (atomicio(read,
which is nice and easy to read. These integer bugs are tedious and hard to spot; a very dangerous combination in open source software as it means only the bad guys tend to look for them
Sigh, wish you could edit Slashdot posts.
The correct link to the department is:
Laboratory for Communication Engineering, and the correct name is Rip Sohan (sorry!)
You're right, they are left over equipment from AT&T Labs Cambridge, which were redeployed in the Laboratory for Communication Engineering at the University of Cambridge.
:-) Feel free to get in touch with the main man behind the phones, Rip Soham, if you are interested in more details (contact details in the link).
But they're more than prototypes, the phones work really well even six years after being built (mainly due to their thin-client architecture, as only the servers need to be upgraded to run more complex services, not the edge phone hardware).
It's a bit of a shock to see this randomly show up on Slashdot, but for those interested readers, here's a WIP paper about what we're doing with them these days (using the Active Bat location system to migrate mobile phone calls via Bluetooth to the nearest environmental phone among other things).
As I said, the paper is very much WIP, and is being hacked up after being freshly rejected from a conference so the link is liable to disappear
As far as I know, no commercially available VoIP phone uses VNC these days, which is a real pity as its a really neat way to offer easily upgradable services to the end user (forget running mobile code on the edge device, compute power is cheap these days).
If I combine the core teams, even the security teams of all the flavors COMBINED, we'll have a hard time finding programmers with stable jobs, let alone an advanced degree in the area or an industrial lab support.
... BSD has "Berkelely" in the name, and the university heritage lives on.
Are you serious? Here's a hint
While MacOS X libraries are from FreeBSD, Darwin (the kernel) is Mach derived and has very little to do with the FreeBSD kernel.
That's not true. The FreeBSD network stack is used in Darwin with a compat layer. Look at OpenDarwin's cvsweb for an example.
Pick and Drop is very cool ... in case anyone is interested, we knocked up an audio-based pick and drop interface a couple of years ago inspired by Rekimoto's work. Cheesy videos and webpage available here, and the academic paper describing the work in more detail.
The idea is that you can use existing devices (like voice recorders, mobile phones, PDAs) that can play or record audio to capture documents and move them around. By playing the sound back to a device (e.g. a print server), it decodes the identifer and downloads it via the higher bandwidth network.
I can only say that it's pretty obvious that wasn't my intention ... if it had occurred to me that this "astroturfing" was a problem, I could have submitted the story anonymously, or used a friend's account, or a hundred other ways to do it properly.
/. by "cunning" use of the 'whois' command, but really - it isn't.
You might think it's clever to post my home address and phone number to
If I've offended, then I apologise.
Err, no ... the camera does all of the image processing, so there is no GPRS or MMS stuff going on.
The idea is that you interact with local interfaces with low-latency (comms over Bluetooth, fast and free), and when/if you want to buy something, you can just go online and pay via your phone bill without having to whip out credit card numbers etc.
Yeah, I think you're right ... live and learn eh? First time I've heard the term 'astroturfing', not going to forget it in a hurry :-)
Give me a break ... where do the disclaimers stop? I mean, the software's being given away for free for non-commercial use, and I think it's of interest to other techies. Notice I didn't submit anonymously.
... I do my bit there as well. But noone cares about that stuff, so why bother talking about it instead of stuff I think is fun?
And don't start spouting "open-source this, open-source that" to me
Sorry but first off, I don't want a camera phone
... the decoding happens in real-time (you see the camera viewfinder, and it highlights tags). Once the main slashdotting dies down, the videos hopefully explain it a bit better.
... I was demonstrating this stuff at a research demo day recently, and we ran a normal Nokia 3650 for a good 8 hours without seriously killing the batteries - that the camera and bluetooth active at the same time.
You're probably posting from the US. In Europe, it's almost impossible to buy a cellphone without a camera these days. You're correct in that I dont particularly want to take pictures with the crappy camera - so why not use it for something useful?
Will this all run within my 2 second attention span?
Pretty much
Not to mention what this would do to the phone's battery life.
Actually, it's not too bad
Since the main site is predictably a bit bogged down, there is also a page at the University of Cambridge Systems Research Group detailing the research side of things. It also has some cool videos :-)
You can find mergemaster in /usr/ports/sysutils/mergemaster in OpenBSD, or as a standard binary package.
The university's link is a bit hosed, so I've mirrored the site and paper here, and you can grab the ISO via BitTorrent from here
Grab the BitTorrent from here (and leave your windows open for a while!)
OpenBSD has FLAVOR and MULTI_PACKAGES exactly for this. Each port has a set of knobs that can be twiddled, and the binary packages are generated and named appropriately.
In OpenBSD, Matthieu Herrb patched XFree86 to use privilege separation so that the main X process can drop root privileges and run as a normal _x11 user. The privileged portion just grants it the ability to open devices it needs and send certain signals.
... it's not hard, just requires the OS to support descriptor passing.
There's no reason why these guys couldn't do the same if they care about security
The OpenBSD Apache chroot()s after its been run, so it loads all the libraries and modules as normal; no need for fancy mounts or copying libraries into the chroot.
> IMP is more fully featured but it also a pain
...
> to install/upgrade/maintain too and its not
> totally standards based.
I'd be interested to know which 'standards' IMP breaks
Note that THERE ARE dependencies that should be taken care of before
building a new kernel, even on -stable.
No, no, no - propolice has only been added into the -current tree, so if you are tracking -stable, continue as before. Only critical fixes go into -stable, certainly nothing as huge as a big GCC patch.
You don't have to change the options in the Makefile you know.
For OpenBSD's PHP port, just do:
$ env FLAVOR="imap gettext mysql gd" make install
and it'll do everything else automagically.
For a full list of possible flavors, do:
$ make show VARNAME=FLAVORS
Different flavor combinations result in a different binary package getting created.
Well, you could replace the 2k kerberos auth with MIT Kerberos ...
n ning/security/kerbsteps.asp
http://microsoft.com/technet/win2000/rsvpker.asp
And 2k clients could still authenticate with no problems, but you have a *NIX based KDC, with the obvious advantages that brings.
Microsoft even publishes a step-by-step guide to doing this!
http://www.microsoft.com/windows2000/techinfo/pla