Sure, the license is nice, but PCC compiles NetBSD's userland five to ten times faster than GCC. If it was only a few percent worse on code generation, it would save vast amounts of time for developers trying to work on large code bases.
GCC is a pig. The point of resurrecting PCC is that it is not a pig.
They factored a four bit number. Quantum computers on this scale have been demonstrated before, but not much progress has been made in the number of qubits people can build. When someone demonstrates something that can factor even a 32 bit number, I'll be much more impressed. I bet it will be some years before they can even handle a 10 bit number -- and they'll need to hit 2048 bit numbers before any of this is of practical importance.
Peter is a security guy. He's written widely used crypto software. He is not a medical imaging specialist. Where did/. get the idea that he's a medical imaging specialist???
The technological revolution feeds itself. Machines are built with machines, computers designed with computers, etc.
Naturally, this leads to an exponential, rather than a linear, pattern of change -- technological compound interest, in other words. Moore's Law and the rest are not accidents or the result of technological planning -- they are the result of technology being applied to improve technology.
It should not be surprising, therefore, that the world of online hypertext and search engines has so rapidly eclipsed the world of print. Change is happening faster and faster.
What I find curious is that people really have so little sense of what the continuation of the exponential curves means to us.
Nanotechnology, machines capable of not just equalling but exceeding biological humans in mental capability, etc., are all likely to show up in coming decades. Everything leads one to the conclusion that there is likely to be more change experienced in the next century than we have experienced in the last million years or longer.
And still, in spite of all of this, people spend their time assuming the future will look something like the present, but perhaps with different fashions and slightly better televisions.
I'm on a couple of the lists that should have been informed. As one example, NetBSD's security officer has received no information from the openssh team at all. I'm unaware of other groups having received official word.
If you are aware of a security team that was informed officially, I'd be interested to hear about it.
This has little to do with Theo's "pride". If there are exploitable bugs in OpenSSH, they have to be found and fixed, and "pride" has nothing to do with it. I'm sure people would search for bugs in a program as critical as ssh whether or not Theo had any involvement.
What I am most upset about is that Theo has not seen fit to send out any sort of official announcement to the various operating system vendor security teams -- or to anyone else -- even though an apparently simple patch is available and could be distributed.
Biometrics are hated by real security geeks.
on
Users feel Password Rage
·
· Score: 4, Insightful
I don't understand this "security experts say biometrics will fix the password problem", since I'm a professional security geek and I don't think that and I know of no fellow security geeks who think that. Indeed, most of us make fun of biometrics when they are mentioned as a solution to such problems.
Biometrics are essentially useless for over-the-net identity verification because you have no way of knowing whether the equipment on the other end has been tampered with. There might be no retinal scanner there at all -- just software that pretends there is one and feeds you faked up scans. There is also no way to change your retinal scan if it is compromised, so if someone finds a way to get information on your retina, they can thereafter fake your scan over the net with impunity. It isn't like your retina can engage in a public key authentication protocol with the equipment -- the equipment just makes a measurement, which once stolen can be replicated and by definition cannot be easily changed. Ditto for fingerprint scanners or any other biometric measuring instrument.
Also, the quality of biometric authentication, even when the scanners are known good and untampered with, is very questionable. The false positive and negative rates are unacceptably high -- measured in percent, not in hundredths or thousandths of a percent. That might be fine for unlocking the weather report, but is completely unacceptable for authorizing a purchase. Worse still, those false identification rates are unlikely to change.
In short, biometrics are not of any use for over the net authentication. They are only useful in very limited applications, like verifying identity at a door with a guard who makes sure you don't tamper with the equipment, and even then only if the system is verifying your identity based on another mechanism of conveying identity (like an ID badge) rather than attempting to determine who you are based on the scan.
Determining who you are based on the scan has an amazing error rate -- put a fingerprint scanner up on a door to identify rather than to verify an ID card and one in ten people will just walk in by putting their thumb up to it after being falsely identified as a user of the system. If you actually need security, such rates are unacceptable.
Anyway, as I said, serious security people rarely mention biometrics in any context, and never for over the net transactions.
Why, then, do biometrics keep getting press? I'm guessing because if you don't know anything about security, biometrics seem like a sexy idea, and because there are so many startups that have millions of dollars gambled on biometrics and would like people to think that they are going to be of some use in the security world.
The guy wants to be able to do things like disconnected operation and file sharing over a WAN. NFS is totally unsuitable for either of those as it provides neither distributed file service (if the server you are getting a file from goes down you lose) or disconnected operation.
NFS is also not a distributed/global file system. It is a pretty primitive way to handle global namespace management compared to stuff like AFS. At best what an automounter lets you do is avoid a few of NFSes problems. Ideally, I'd say this guy should try to see if he can get the U. Michigan disconnected AFS stuff out of Honeyman and company and see if he can port it to OpenAFS.
Next issue of "Planetary" -- When?
on
Ask Warren Ellis
·
· Score: 2, Insightful
So, I hate to ask this, but Planetary has been coming out at a very slow crawl, and some of us are waiting desperately for the next issue. When is it likely to come out? And is the slow pace just because you have so many projects going at once?
Ben Stein's comments seem to be reasonably accurate, if you read them. We do indeed live in a country with a crippled education system, general contempt for intellectual activity among the bulk of the population, etc. I don't agree with absolutely everything he said, but overall, it is hard to argue.
All the foul language and no-nothing replies I've seen here in response to his article are evidence for his contentions, by the way.
Your comment is rather vague. Let me be more specific.
Lets say that you have an smtp daemon. With systrace, I can very easily elevate it to be able to open port 25 on the system, and restrict it so that it can't fork or exec any programs and can do no i/o other than writing to files in/var/mail.
Sure, you can theorize about how evil and complicated this is, but the truth is in one fell swoop I've made it fiendishly difficult to exploit the smtp daemon -- and in most cases I don't even need to have the daemon be the least bit aware of how systrace works. Once I've done this, I can't make the smtp daemon fork a/bin/sh for me, I can't make it write to random files on the system, indeed, I can barely write a remote exploit for it at all. Add in a little chroot and other magic and suddenly you have a very hardened program.
Most of your comment seems to consist of platitudes about simplicity, not any actual experience with using systrace in a practical system. It very much adds security to the way systems run, and it is completely in the spirit of most modern security aware code, like the Postfix mailer or privilege seperated ssh.
What you're saying is "if the mechanism itself has a horrible bug might that let you break security?" Well, of course.
However, if there is some sequence of syscalls that lets you, say, get root, well, you have root, and the game is over. What systrace means is, if you have a system with a reasonably bug free set of system calls, you can reduce or eliminate the vulnerability that misbehaving root privileged programs might cause.
As an example, is really far better for, say, your ntpd to only have the ability to run the normally root prived ntp_adjtime call rather than to be able to do anything root could do. Systrace also lets you give up the ability to run calls like fork and exec that a given program may not need (ntpd does not need them). That way, if someone remotely breaks ntpd, well, they don't own your machine -- at best they can crash your ntpd. They can't fork a new program (a typical exploit would fork a privileged/bin/sh), and they have no access to "normal" root prived calls.
The answer is you can't tell the kernel "I'm Apache." Obviously a mechanism that just let you do that would be trivial to evade. The kernel can easily know whether you are the apache program or not, however, because it knows the inode backing your executable -- there is no way to forge that. This is the same way the kernel knows that you have a suid bit -- it looks at the inode for what it is executing when it executes it.
The systrace mechanism is a very nice one. Most on-system exploits these days are caused by suid programs being exploited before they give up privileges (and many don't give up privs ever). By only giving a program just the privs it needs, you can avoid having to have root privs available to the programs at all. You can't exploit privileges you never have had.
The method employed is somewhat fiendish. A systraced program is "mastered" by a systrace daemon that gets information on all its system call activities and either thumbs up or thumbs down particular requests. (For performance reasons, things get fast pathed in many instances so the upcall doesn't have to happen.)
Because of the way that this works, via a userland policy engine, the systrace daemon (which is user code) can use any method it likes to determine how to implement the policy. The way it is currently implemented, the systrace program reads a policy file associated with particular programs and makes decisions that way.
There is no need for a program to authenticate to the kernel because the program itself has no knowledge of the policy and cannot evade it in any reasonable way.
The mechanisms involved are still evolving a bit, but Niels has come up with a bunch of really good tricks here. I don't know that systrace is a finished mechanism as much as a toolkit for building new and more interesting mechanisms that are in the tradition of ACLs but much more flexible.
I'll say it again: the change appeared in NetBSD first, so one should mention both NetBSD and OpenBSD here, and please give credit to Niels Provos, the author of systrace and thus the guy who's been doing all the hard work here.
I hate to be a bitch here, but the feature was added to NetBSD first. I don't mean to imply NetBSD is better than OpenBSD, but maybe some equal billing would have been in order? And by the way, what happened to crediting the author of the code? The work was all done by Niels Provos, who's a damn good security guy.
1) The story in no way credits Niels Provos, the author of systrace.
2) The story does not mention that this feature was added to NetBSD first.
I don't mean to claim "NetBSD is better" or anything, but at least say "OpenBSD and NetBSD" or "NetBSD and OpenBSD" or something, not "OpenBSD". Also, PLEASE credit the guy that did the work, eh?
As I said in a previous message, PC Weasels. You'll never need to be physically near the machine again. They're beautiful.
Re:PC Weasels are often better than KVM switches.
on
USB KVMs Compared
·
· Score: 2
That's the point. You DON'T need "true" console access with a monitor and keyboard if you have a PC Weasel. You say "when you need it, nothing else will suffice" but that's exactly the point -- with PC Weasels, you never need it, because the remote management is as good or better than what you can do locally. You NEVER need physical presense again unless what you want to do is replace bad hardware.
Re:PC Weasels are often better than KVM switches.
on
USB KVMs Compared
·
· Score: 2
I've bought lots of boards with "server BIOSes" in the past, and they have never done as well as a PC Weasel for the job.
1) The serial BIOSes often do not work very well. Often they have trouble letting you do remotely what you can do locally even though that is what they're supposed to do for you. 2) They don't provide remote reset or watchdog timers. People then resort to additional kludges like remotely controlled power strips, etc.
In general, the PC Weasel "Does It Right".
PC Weasels are often better than KVM switches.
on
USB KVMs Compared
·
· Score: 4, Informative
KVM switches are okay if you're just trying to avoid having more than one monitor for a couple of boxes you sit in front of, but they suck for managing a lot of hosts in real production work. I find that using a PC Weasel and a terminal server works a lot better than a KVM switch for remote management of Unix boxes running on PC hardware. KVM switches are okay some of the time, but PC Weasels rock!
Slashdot Mirror
Sure, the license is nice, but PCC compiles NetBSD's userland five to ten times faster than GCC. If it was only a few percent worse on code generation, it would save vast amounts of time for developers trying to work on large code bases.
GCC is a pig. The point of resurrecting PCC is that it is not a pig.
They factored a four bit number. Quantum computers on this scale have been demonstrated before, but not much progress has been made in the number of qubits people can build. When someone demonstrates something that can factor even a 32 bit number, I'll be much more impressed. I bet it will be some years before they can even handle a 10 bit number -- and they'll need to hit 2048 bit numbers before any of this is of practical importance.
Peter is a security guy. He's written widely used crypto software. He is not a medical imaging specialist. Where did /. get the idea that he's a medical imaging specialist???
Yes, Postfix is now the default MTA.
Postfix was made the default mailer.
At this point, all hashes other than SHA-1 (for practical purposes) are known broken.
The paper is pretty definitive about MD4, MD5, HAVAL-128, RIPEMD and SHA-0. SHA-1 is rumored to be about to fall too.
And yes, this is bad.
The technological revolution feeds itself. Machines are built with machines, computers designed with computers, etc.
Naturally, this leads to an exponential, rather than a linear, pattern of change -- technological compound interest, in other words. Moore's Law and the rest are not accidents or the result of technological planning -- they are the result of technology being applied to improve technology.
It should not be surprising, therefore, that the world of online hypertext and search engines has so rapidly eclipsed the world of print. Change is happening faster and faster.
What I find curious is that people really have so little sense of what the continuation of the exponential curves means to us.
Nanotechnology, machines capable of not just equalling but exceeding biological humans in mental capability, etc., are all likely to show up in coming decades. Everything leads one to the conclusion that there is likely to be more change experienced in the next century than we have experienced in the last million years or longer.
And still, in spite of all of this, people spend their time assuming the future will look something like the present, but perhaps with different fashions and slightly better televisions.
I'm on a couple of the lists that should have been informed. As one example, NetBSD's security officer has received no information from the openssh team at all. I'm unaware of other groups having received official word.
If you are aware of a security team that was informed officially, I'd be interested to hear about it.
This has little to do with Theo's "pride". If there are exploitable bugs in OpenSSH, they have to be found and fixed, and "pride" has nothing to do with it. I'm sure people would search for bugs in a program as critical as ssh whether or not Theo had any involvement.
What I am most upset about is that Theo has not seen fit to send out any sort of official announcement to the various operating system vendor security teams -- or to anyone else -- even though an apparently simple patch is available and could be distributed.
I don't understand this "security experts say biometrics will fix the password problem", since I'm a professional security geek and I don't think that and I know of no fellow security geeks who think that. Indeed, most of us make fun of biometrics when they are mentioned as a solution to such problems.
Biometrics are essentially useless for over-the-net identity verification because you have no way of knowing whether the equipment on the other end has been tampered with. There might be no retinal scanner there at all -- just software that pretends there is one and feeds you faked up scans. There is also no way to change your retinal scan if it is compromised, so if someone finds a way to get information on your retina, they can thereafter fake your scan over the net with impunity. It isn't like your retina can engage in a public key authentication protocol with the equipment -- the equipment just makes a measurement, which once stolen can be replicated and by definition cannot be easily changed. Ditto for fingerprint scanners or any other biometric measuring instrument.
Also, the quality of biometric authentication, even when the scanners are known good and untampered with, is very questionable. The false positive and negative rates are unacceptably high -- measured in percent, not in hundredths or thousandths of a percent. That might be fine for unlocking the weather report, but is completely unacceptable for authorizing a purchase. Worse still, those false identification rates are unlikely to change.
In short, biometrics are not of any use for over the net authentication. They are only useful in very limited applications, like verifying identity at a door with a guard who makes sure you don't tamper with the equipment, and even then only if the system is verifying your identity based on another mechanism of conveying identity (like an ID badge) rather than attempting to determine who you are based on the scan.
Determining who you are based on the scan has an amazing error rate -- put a fingerprint scanner up on a door to identify rather than to verify an ID card and one in ten people will just walk in by putting their thumb up to it after being falsely identified as a user of the system. If you actually need security, such rates are unacceptable.
Anyway, as I said, serious security people rarely mention biometrics in any context, and never for over the net transactions.
Why, then, do biometrics keep getting press? I'm guessing because if you don't know anything about security, biometrics seem like a sexy idea, and because there are so many startups that have millions of dollars gambled on biometrics and would like people to think that they are going to be of some use in the security world.
The guy wants to be able to do things like disconnected operation and file sharing over a WAN. NFS is totally unsuitable for either of those as it provides neither distributed file service (if the server you are getting a file from goes down you lose) or disconnected operation.
NFS is also not a distributed/global file system. It is a pretty primitive way to handle global namespace management compared to stuff like AFS. At best what an automounter lets you do is avoid a few of NFSes problems. Ideally, I'd say this guy should try to see if he can get the U. Michigan disconnected AFS stuff out of Honeyman and company and see if he can port it to OpenAFS.
So, I hate to ask this, but Planetary has been coming out at a very slow crawl, and some of us are waiting desperately for the next issue. When is it likely to come out? And is the slow pace just because you have so many projects going at once?
Ben Stein's comments seem to be reasonably accurate, if you read them. We do indeed live in a country with a crippled education system, general contempt for intellectual activity among the bulk of the population, etc. I don't agree with absolutely everything he said, but overall, it is hard to argue.
All the foul language and no-nothing replies I've seen here in response to his article are evidence for his contentions, by the way.
Your comment is rather vague. Let me be more specific.
/var/mail.
/bin/sh for me, I can't make it write to random files on the system, indeed, I can barely write a remote exploit for it at all. Add in a little chroot and other magic and suddenly you have a very hardened program.
Lets say that you have an smtp daemon. With systrace, I can very easily elevate it to be able to open port 25 on the system, and restrict it so that it can't fork or exec any programs and can do no i/o other than writing to files in
Sure, you can theorize about how evil and complicated this is, but the truth is in one fell swoop I've made it fiendishly difficult to exploit the smtp daemon -- and in most cases I don't even need to have the daemon be the least bit aware of how systrace works. Once I've done this, I can't make the smtp daemon fork a
Most of your comment seems to consist of platitudes about simplicity, not any actual experience with using systrace in a practical system. It very much adds security to the way systems run, and it is completely in the spirit of most modern security aware code, like the Postfix mailer or privilege seperated ssh.
What you're saying is "if the mechanism itself has a horrible bug might that let you break security?" Well, of course.
/bin/sh), and they have no access to "normal" root prived calls.
However, if there is some sequence of syscalls that lets you, say, get root, well, you have root, and the game is over. What systrace means is, if you have a system with a reasonably bug free set of system calls, you can reduce or eliminate the vulnerability that misbehaving root privileged programs might cause.
As an example, is really far better for, say, your ntpd to only have the ability to run the normally root prived ntp_adjtime call rather than to be able to do anything root could do. Systrace also lets you give up the ability to run calls like fork and exec that a given program may not need (ntpd does not need them). That way, if someone remotely breaks ntpd, well, they don't own your machine -- at best they can crash your ntpd. They can't fork a new program (a typical exploit would fork a privileged
The answer is you can't tell the kernel "I'm Apache." Obviously a mechanism that just let you do that would be trivial to evade. The kernel can easily know whether you are the apache program or not, however, because it knows the inode backing your executable -- there is no way to forge that. This is the same way the kernel knows that you have a suid bit -- it looks at the inode for what it is executing when it executes it.
The systrace mechanism is a very nice one. Most on-system exploits these days are caused by suid programs being exploited before they give up privileges (and many don't give up privs ever). By only giving a program just the privs it needs, you can avoid having to have root privs available to the programs at all. You can't exploit privileges you never have had.
The method employed is somewhat fiendish. A systraced program is "mastered" by a systrace daemon that gets information on all its system call activities and either thumbs up or thumbs down particular requests. (For performance reasons, things get fast pathed in many instances so the upcall doesn't have to happen.)
Because of the way that this works, via a userland policy engine, the systrace daemon (which is user code) can use any method it likes to determine how to implement the policy. The way it is currently implemented, the systrace program reads a policy file associated with particular programs and makes decisions that way.
There is no need for a program to authenticate to the kernel because the program itself has no knowledge of the policy and cannot evade it in any reasonable way.
The mechanisms involved are still evolving a bit, but Niels has come up with a bunch of really good tricks here. I don't know that systrace is a finished mechanism as much as a toolkit for building new and more interesting mechanisms that are in the tradition of ACLs but much more flexible.
I'll say it again: the change appeared in NetBSD first, so one should mention both NetBSD and OpenBSD here, and please give credit to Niels Provos, the author of systrace and thus the guy who's been doing all the hard work here.
I hate to be a bitch here, but the feature was added to NetBSD first. I don't mean to imply NetBSD is better than OpenBSD, but maybe some equal billing would have been in order? And by the way, what happened to crediting the author of the code? The work was all done by Niels Provos, who's a damn good security guy.
I really hate to say it, but:
1) The story in no way credits Niels Provos, the author of systrace.
2) The story does not mention that this feature was added to NetBSD first.
I don't mean to claim "NetBSD is better" or anything, but at least say "OpenBSD and NetBSD" or "NetBSD and OpenBSD" or something, not "OpenBSD". Also, PLEASE credit the guy that did the work, eh?
As I said in a previous message, PC Weasels. You'll never need to be physically near the machine again. They're beautiful.
That's the point. You DON'T need "true" console access with a monitor and keyboard if you have a PC Weasel. You say "when you need it, nothing else will suffice" but that's exactly the point -- with PC Weasels, you never need it, because the remote management is as good or better than what you can do locally. You NEVER need physical presense again unless what you want to do is replace bad hardware.
I've bought lots of boards with "server BIOSes" in the past, and they have never done as well as a PC Weasel for the job.
1) The serial BIOSes often do not work very well. Often they have trouble letting you do remotely what you can do locally even though that is what they're supposed to do for you.
2) They don't provide remote reset or watchdog timers. People then resort to additional kludges like remotely controlled power strips, etc.
In general, the PC Weasel "Does It Right".
KVM switches are okay if you're just trying to avoid having more than one monitor for a couple of boxes you sit in front of, but they suck for managing a lot of hosts in real production work. I find that using a PC Weasel and a terminal server works a lot better than a KVM switch for remote management of Unix boxes running on PC hardware. KVM switches are okay some of the time, but PC Weasels rock!
FreeBSD's "ports" are ported software, not platforms FreeBSD runs on. The terms are different.
(And yes, NetBSD also has thousands of ported applications -- we use a system derived from the FreeBSD ports mechanism.)