It seems that to make the mini even worth using is to spend lots of money on upgrades.
No, this is not true. Remember you are at/. No matter how fast a computer people here have, many of them will want to tinker with thier computers to make them faster. Like people who soup up cars.
The tinkering is fun.
The Mac mini is a fantastic little machine. I have an AMD XP2800+ with 2 7200 RPM drives and 2GB of DDR RAM, but I mostly use my little Mac mini because of Mac OS X. A faster computer is always nicer, but part of the minis appeal is its size and price. It runs OS X nicely given this in mind.
I have the 1.42GHz mini with the 80Gb drive and 1GB RAM.
I type in "theo de raadt", just for some obscure example which I figured would get some results, since I'm subscribed to misc@openbsd...
Somewhere between a quarter of a second and perhaps a half a second of finishing typing his name, the results are up (386 total).
If I type in "network", same deal. A split second I've got results (1134) and then another split second later they're broken up into 9 categories.
I am impressed. I've used programs like iSys before, however this is integrated from the desktop all the way to the command line.
At first I was put off by seeing results come up as a type and this caused me to type slower and make mistakes because I was distracted by that and would look at them before they were as meaningful as they could be. I've since learned to just force myself to concentrate on completing the phrase and then looking.
Best of luck trying to get rid of the heat. Remember, convection won't work, only radiation.
Silly, convection couldn't work because there is no real "up" in space. You know? Heat rises? I therefore propose the use of fans. Imagine how fast the fans could spin in the vacume of space!!! They would be much more effective "up there" than down here with all this inefficient "atmosphere" crap. The fans could also redundantly double for propulsion when needed.
Why has NASA not thought of these things? NASA really ought to be hiring real geniuses like many of the other gifted/. readers here. Oh well, you know what they say, "it's not what you know, it's who you know".
There used to be talk that the V. 34+ speeds of 33.6 kbps represented the very fastest that US phone lines could ever handle. It just wasn't scientifically possible to go any faster.
The 33.6 limit was NOT due to the phone lines, it was due to the equipment at the end of the phone lines at the telephone exchange.
At the telco end, telephone audio would be converted to and from analog and digital so that an analog signal could be presented to your phone, but on the other side a digital signal could become part of a digital packet switched network to efficiently be routed to where your phone call needed to go.
Upgrade that equipment or allow the elimination of conversion between analog and digital and you upgrade the limits. The limits of the copper lines themselves are much higher than 33.6kbit/s.
I think God is the correct word here. Is it just me, or are those videos reminiscent of one of these crazy religious evangelists that we see on TV?
He is commanding the faithful it would seem. What a fucking wanker. "Give it up for me!"? I think maybe he should give up the jelly filled Krispy Kremes and go on a long term course of sedatives and psycho therapy.
I'm still trying to understand how a collision technique, where the attacker has on control over what the hash will be, can be useful for injecting bogus data into a bittorrent or a similar modern p2p network?
Ah, I didn't say the act of finding a collision would be useful. Since it is impractical. What I am saying, is that the only option is an impractical one. In other words, not really feasible.
If you can exhaustively search for random data that gives the same hash, then that is useful because you can serve it as the original. But that if is a pretty huge if. ; )
Remember that those 2^69 "operations" (each many CPU cycles) are for a SHA1 "collision" attack. A "preimage" attack that would be necessary to inject corrupt data into a p2p network using SHA1 (such as Bittorrent) is much harder and has not been discovered and published.
Paul,
A pre-image attack is NOT what is needed to inject corrupt data into a p2p network which uses SHA1. The calculation of the preimage (besides usually being impossible) buys you nothing. Why would you tackle this beast of a problem head-on when the pre-image can simply be downloaded!? Yes, that's right, the file itself (or portions depending on how the hashing is done), IS the pre-image. Having the pre-image buys you nothing in creating alternate data with the same SHA1 hash, because what is needed is the convienience of being able to craft both the good and bogus data.
SHA1 is used in different ways. It can be used for authentication, whereby only the hash is compared and the pre-image is never stored. It can be used to authenticate a file where the file is seperated from the hash in such a way that both (mostly just the hash) cannot be altered. Or it can be used as a strong checksum for a file, in which case the hash is sent with the file or openly associated with the file, for the purpose of making sure data transfered correctly. With something like bittorrent, you're probably not going to be able to change the publically served hash in the torrent file along with that hash that the peers are aware of, so your only option is to find a collision.
If you can control the creation of both good data and bogus data, then you can do this against SHA1 in a much reduced but still very difficult process, thanks to the new found weakness. But if all you control is the creation of bogus data, then you are at the mercy of the full strength of SHA1.
Pre-image attacks have NOTHING to do with injecting bogus data into a hash protected P2P network. The pre-image is available to all. What you need do perform is a COLLISION attack.
Pre-image attacks are used when the pre-image or data/file is unknown. This is not the case with P2P. The pre-image can simply be downloaded. Confirmed pre-image attacks can be IMPOSSIBLE, because there are an infinite number of possible pre-images of varying sizes which will provide a collision or otherwise more than one possible pre-images of the same size as the real pre-image. There is no way to know which equivalent pre-image is the real pre-image unless the full fixed data space is searched and only one pre-image is found (this would require a pre-image of the same size or smaller than the hash size). The only way to be sure that you have the correct pre-image size, would be to preview the real pre-image, in which case there would be no point at all.
A hash algorithm takes an arbitrary number of input bits and generates a message digest of a fixed number of hash bits. Therefore, if your input data is larger than the hash data, then hashes have to be able to represent more than one input data set, because the hash is of a finite size.
They also claim that they can encode files which can be broken later. This is more feasible, since this requires the reduced collision attack. Of course, how feasible and practical is this really? I highly doubt they can deliver on this given the amount of data the music and movie industry will want protected and the whole 2^69 thing. ; )
Systems like FreeBSD and SOlaris (at least on specific hardware) allow for going quite a bit beyond a chroot. Please look into it soemtime
I didn't say OpenBSD was the best solution for this. You seem to be getting defensive now and reading way more into what I am writing. I am showing solutions which OpenBSD provides, without any claim of comparitive effectiveness. It's not like I came in and said Solaris containers or DSD are a waste of time since OpenBSD has chroot!
I find it pretty amusing that I'm being told on/. to look into this stuff.
You can just keep ignoring this and point at all good OpenBSD features, well, we agreed quite a few posts ago about their attitude and featureset.
I'm not trying to be a fanboy. I'm just stating things as I see them. I have not ignored anything. How many times do I have to say that OpenBSD is not perfect and does not always fit?
Maybe it is just me, but I end up very often eneding things (one thing in particular, see above) that OpenBSD does not supply.
I often choose something other than OpenBSD.
More recently I have found myself ending up using more and more SMP hardware, and while OpenBSD has become a valid option now on that in some cases, it is far from what I end up needing most often, for exactly that thing, an internet facing machine running some mix of services.
I wouldn't dare use OpenBSD for SMP in production at the moment. Nor would I use NetBSD or FreeBSD. If the only way to get acceptable performance to meet the needs was to go SMP, the it would typically be Solaris or Linux.
Do you not think this discussion has become a little ridiculous? My original point and all along, has been that I don't believe the other BSD's can just be brought up to the security which OpenBSD provides, WITH A LITTLE EFFORT. Now all of a sudden we're talking about Solaris on "specific hardware" or a specific area of FreeBSD? I have been talking about overall security all along and you pick weaker points in OpenBSD which are covered very well elsewhere and go to town on them. Yet I have said time and time again, that OpenBSD is not perfect and does not always fit well.
With a small amount of effort on Free or Net, you're going to get all the benefits of OpenBSD's ongoing audits, design stance and active mechanisms?
Absolutely, and those features are extremely usefull to tackle specific classes of attacks.
Yes specific classes, however very often exploited attacks.
Quite a few security breaches result from simple misconfigurations, and none of the mentioned mechanisms does much to prevent those while of course they do help prevent exploitation of a whole bunch of possible bugs that can result in privilege escalation, so there is a level of containment there.
I'm not talking about user mess ups though. I'm talking about OpenBSD. No matter what the OpenBSD team does, I don't think they could ever cater for the users who can't help but get themselves into trouble.
For services like a public dns, smtp and in many cases http, I prefer being able to seperate those from the host environment so that even in case of a local root compromise, the effect is still contained within an environment specifically built for that one service.
No problem, in fact Apache ran in chroot by default, as of OpenBSD 3.2, Nov 1st 2002. named chroot by default, as of OpenBSD 2.4, Dec 1st 1998 and smtpd was default chroot at least in 2000.
You use the word prefer as if you are choosing one over the other. Wouldn't you rather both to be sure? Especially if it comes like this as default?
For many a situation I found having to put in quite a bit of efford to make things secure and functionally what is desired (I have yet to find the customer who only needs a basic apache and smtp server), so a little extra efford while setting things up is not too much of a problem, esp. when it saves efford for maintenance later on.
Yes, life can be tough.
Ideally, you'd have all the openbsd security mechanisms together with what I just described and something like mandatory access control (having acl support makes live a lot easier and safer when running samba on an internal server for example)
Yes, I would like this.
As long as we can't have that, I'll have to make a choice, and I believe that choice is not as straightforward untill most peope only actually need a default install.
OpenBSD is an excellent choice as long as it at least can be configured to meet all needs. Obviously if it can't currently support a need then it must be overlooked. But this is a far cry from overlooking it just if the default configuration does not meet the needs. It's not like the default install is as functional as it gets. We all know that OpenBSD is quite the opposite.
In my opinion, that is only true if what you need happens to fall within the focus of the OpenBSD team.
By those general duties, I am refering to the usual suspects: DNS, FTP, HTTP, POP3, SMTP, etc. W^X, Propolice and Stackghost tackle some pretty generic security problems which can plague these services and are responsible for a large percentage of successful attacks. However these are not the only services that OpenBSD supports and the active security mechanisms work regardless of the application being protected.
In other words, they are limited in what they offer, but when they offer something they do it well.
I agree. But don't forget that the original argument is regarding OpenBSD security (obviously of what it actually supports), not OpenBSD suitability for everything.
On another note, I find it interesting how you (tho in a friendly way) get somewhat defensive as soon as someone suggests there may be other and even better solutions then OpenBSD while at the same time agreeing that it is not perfect. I don't think there is any reason for this defensiveness, noone is saying it is bad or was attacking it in any way.
You are preceiving something which is not there. But this is not hard when we are just passing text to each other.
In my day to day work and personal life, I choose to mostly use NetBSD, OpenBSD, Mac OS X and Windows XP. When I get my hands on some nice dual-core Opterons, I will probably go back to FreeBSD for a lot of what I do at work. At the moment NetBSD is mostly what I use. I use OpenBSD for my servers and firewall/gateways, NetBSD for internal servers and workstations (R&D), OS X for my desktop work and XP because sometimes I have no other option.
I am not getting defensive. I just don't think getting NetBSD or FreeBSD up to par on the security OpenBSD provides can be done with a little added effort. By the same token, I don't think getting OpenBSD to perform as quickly as NetBSD can be done with a little added effort. Same deal when the dust settles on FreeBSD and dual-cores are the norm, although probably to a much greater extent.
However, there are also other platforms which implement security mechanisms, and at times ones that OpenBSD does not have.
I wouldn't deny that.
My point has been that there are many active security mechanisms built into OpenBSD, which take it beyond what is just easily configurable on other BSD's. Privilege Seperation work is one small part of the whole and it is very far from the strongest example. W^X, Propolice and Stackghost (sparc) are transparent, effective and cheap on system resources and come as part of the whole as default. You don't have to apply patches and recompile only to find lots of binaries no longer work or that the new mechanism itself has caused a remote root vulnerability.
I realise OpenBSD as it stands is not perfect, lacks some security mechanisms and is not always the best fit. But it seems to have the highest strength for general internet facing duties and is beyond taking another BSD and just adding a little extra effort to security.
In other words, this is a good reason to use openssh, but in itself not an argument for (or against) OpenBSD.
An operating system is more than just a kernel.
It was OpenBSD developers who developed OpenSSH and added priv sep functionality. OpenSSH is just one example of priv sep work done and ready to use in default OpenBSD installs and they continue to work in that area and many other security enhancing areas. That's my point. That they cover many areas with a focus on security and we now all have priv sep OpenSSH thanks to their efforts.
This is a single example application out of many, using a single example security mechanism out of many, which has been developed (the code, not the concept) on and primarily for OpenBSD by OpenBSD developers. And you think this is not an argument for OpenBSD when they have these skills and focus?
I just wanted to point out that privilege seperatiopn is not an operating system issue, it is an application issue,
My previous statement, "Yes but priv sep requires code changes for each privilege seperated application. Some apps are particularly difficult to do this with, like ssh.", does not refute that.
and for many relevant applications where OpenBSD has a default install with privilege seperation, you will find that other platforms have the same.
My original point, is that they roll out many security mechanisms and this is just one of them.
Yeah, we'll just have to content ourselves with our mere 64 bit Windows and Linux, and envy you cutting-edge Apple users with your 32 bit OS.
Just because an OS can be made to compile for 64bit, doesn't make it cutting edge if it slows down and you don't end up needing more than 32bit space.
OS X display functionality remains 32bit on purpose for performance reasons, for example. There is a lot to Apple's "cutting edge" OS that is irrelevant of whether it is 32bit or 64bit. 64bit doesn't just magically make an OS better if the OS is not going to be used to exploit the specific benefits that 64bit brings.
As far as I am concerned, the Tiger is the top of the line when it comes to cats. People keep refering to the Lion as "the king of the jungle", when in fact Lions mostly laze around in the plains, eat what their women catch and get a little bit of nookie every now and then only when their women want it.
Meanwhile, the Tiger rules the jungle as king, is much larger than pussy lions, has a real "lion heart" so to speak and would kick a lions arse any day.
Lions are over rated. I hope no newer releases of OS X will be called Lion, because Lions suck. I mean come on, they get chased away by hyenas! A tiger would never stand for that kinda shit, the hyenas would be desert.
Okay, now since we have established that the Tiger is indeed the king of the jungle and the master of his domain and as such, is "the top of the line in cats", I feel a newer line of naming is in order. I would like to suggest rodent names and would very much like to see the next version of Apple's OS X be:
Mac OS X Beaver, complete with yet another hairy box. I can already imagine the hairy desktop wallpaper I will use and can offer gigabytes of potential official Apple OS X Beaver wallpaper to Apple if they need it.
"Stealth mode", with respect to firewalls, is little more than a marketing catch phrase. The biggest positive thing that it does do for users, is make them feel safer. I have detected my own "stealth mode" firewalled hosts easily with nmap and know of techniques to make it even easier to do if the "stealth" host is at least one router away.
-- People think George Bush is dumb because he's not articulate; just like Stephen Hawking.
Stephen Hawking has a motor neurone disease, meaning his difficulties are purely physical. George Bush on the other hand, does not, he is just a dumb shit. A dumb shit who continues in his daddies footsteps, killing innocent children.
privilege seperation is a technique that can be employed on any Unix and is nowhere OpenBSD specific, their developers do use it where they can tho it seems.
Yes but priv sep requires code changes for each privilege seperated application. Some apps are particularly difficult to do this with, like ssh. But after a lot of effort, they did it. So there is a huge gap between "can be" and "is".
As I've said before, OpenBSD is not perfect (what is?). But it is still one of the best choices for security and continues to advance. It obviously is not going to fit into every need.
Not to mention the passive efforts such as the audits and wholesale migrations away from potentially dangerous code.
Sure it might not be perfect (what is?), but I don't see how anyone can claim that any other BSD can just be configured with a little effort to match OpenBSD's security. They specifically balance everything they do on security and true freedom. Teams of people working hard for years on such a specific area, yet you think it can easily be matched with a little effort with another BSD?
How often have you read an advisory against the BSD's, which stated "OpenBSD not vulnerable" and "OpenBSD fixed this x months ago"?
That implies he doesn't know much about BSD. Advocating Open as a first install then, might not be the best of ideas...
"Thrown into the deep end" mean anything to you?
Read OpenBSD documentation, use OpenBSD, repeat and persist until it is crystal clear. What better way to learn than to be confronted with problems, research them and conquer them?
I am not really impressed with NetBSD or FreeBSD documentation, especially compared with OpenBSD documentation. Do you advocate learning from a system that does more for you and explains less?
If someone asked me what the best way to learn linux is, I would suggest Linux From Scratch. After that, all the distros will probably look restrictive and broken to most people who got the most out of LFS.
they generally assume you will *not* be dual-booting.
Before the days of my house having tens of operational computers, I used to dual boot OpenBSD often. For a long while I had two Seagate 20GB disks which I was booting between OpenBSD, Debian GNU/Linux, Windows 2000, QNX, OpenBSD, FreeBSD, BeOS 5 PE and Windows NT 4.0. Yes, OpenBSD was on each disk. One was my main OS and the other I used for testing.
This was mostly for my learning. Smart Boot Manager is great!
I never could get Solaris 8 x86 or SCO UnixWare to play well with other operating systems on the same disk.
OpenBSD's installer might be a shock to a newbie who is used to typical Linux installers, or even FreeBSD or NetBSD. But I love it! It is fast, straight forward and functional. Just read the fine documentation and then enjoy it from then on.
I have been trying to install NetBSD 2.0 across multiple spindles and I can't seem to find a way to do it without loosing my disk configuration when moving on to the next disk. I resorted to installing on one disk, booting up from it and then creating the partition, slices and file systems manually, moving onto them what I wanted and then updating fstab. What a pain. OpenBSD deals with this no problem in the basic text installer. Trying this recently with NetBSD, I realised how spoiled I have been with OpenBSD.
The OpenBSD installer is anti-bloat all the way. I can install OpenBSD on a modern PC in about 3 minutes and OpenBSD with X in about 5. Sometimes after installing OpenBSD, simply typing "startx" brings X up without configuring it.
And once OpenBSD it is installed... pkg_add almost always works perfectly for every available package.
I can't for the life of me, figure out what you mean when you say the OpenBSD installer is aimed at the tin foil hat user? I love the fact that I can easily modify boot media to install from a console port. Why bother with graphical fluff when installation is just an occasional means to an end. It's not like you want to spend any great amount of time in an installer.
If I wanted to install a BSD on my little home router/gateway, just for the sake of playing around with BSD, which BSD is the one to cut your teeth on?
I moved to OpenBSD full time years ago after I discovered the high quality documentation (the man pages mostly). Sometimes when I need to use something other than OpenBSD I am reminded of how great their doco really is. Now there are also lots of great quality dead tree books too.
For learning, I think good quality texts as a guide and reference and a clean consistent platform are important. So I would recommend OpenBSD for that. You should suffer much less frustration if you are willing to read and use OpenBSD.
For a firewall/gateway, OpenBSD is the native home of pf.
To dispose of the harddrive, you must physically destroy it, basically because the drives have gotten too smart.
Drives have been doing this for at least the past 10 years that I know of. My old WD Caviar and Maxtor 340MB drives did that around '94-'95.
This is the reason that hard drives suddenly started appearing on the market with seemingly no bad sectors to be marked by the file system to avoid. The days of seeing "B" blocks in Norton Disk Doctor and trying to "recover" them were mostly over. The truth was that there were bad sectors, but they were remapped to spares to make drives look good and help to guarantee minimum storage. Due to this, if you had a drive that did exhibit bad sectors, because the spares were all used up, then you had a really bad drive. I always took such drives back.
Dead is boolean. You are either dead, or you are not dead. There is no "mostly dead" like in The Princess Bride. The closest you get is "almost dead", which we call dying. Attempts to call a hard drive which still works "dead" will be met with contempt by more reasonable people.
I have resurected disk images from hard drives which would not spin long enough to complete the task. You know when a drive starts that click - spin down - spin up - click - spin down, etc syndrome? As far as I am concerned, a drive such as that is dead. However, I have found that Ghost will happily wait for blocks to become available while I unplug the power from such a drive and plug it back in. I get non-corrupt Ghost images doing this multiple times until the process completes and I can restore the image to a good drive.
Would you call a drive that will run for no more than 2 minutes dead? I would. Yet I can image such a drive (before it decides to never spin up again).
As far as destroying a really busted drive goes, a caustic soda / water mixture poured into the hole under one of the "void if removed" stickers does wonders. ; )
Slashdot Mirror
It seems that to make the mini even worth using is to spend lots of money on upgrades.
/. No matter how fast a computer people here have, many of them will want to tinker with thier computers to make them faster. Like people who soup up cars.
No, this is not true. Remember you are at
The tinkering is fun.
The Mac mini is a fantastic little machine. I have an AMD XP2800+ with 2 7200 RPM drives and 2GB of DDR RAM, but I mostly use my little Mac mini because of Mac OS X. A faster computer is always nicer, but part of the minis appeal is its size and price. It runs OS X nicely given this in mind.
I have the 1.42GHz mini with the 80Gb drive and 1GB RAM.
I type in "theo de raadt", just for some obscure example which I figured would get some results, since I'm subscribed to misc@openbsd...
Somewhere between a quarter of a second and perhaps a half a second of finishing typing his name, the results are up (386 total).
If I type in "network", same deal. A split second I've got results (1134) and then another split second later they're broken up into 9 categories.
I am impressed. I've used programs like iSys before, however this is integrated from the desktop all the way to the command line.
At first I was put off by seeing results come up as a type and this caused me to type slower and make mistakes because I was distracted by that and would look at them before they were as meaningful as they could be. I've since learned to just force myself to concentrate on completing the phrase and then looking.
Best of luck trying to get rid of the heat. Remember, convection won't work, only radiation.
/. readers here. Oh well, you know what they say, "it's not what you know, it's who you know".
Silly, convection couldn't work because there is no real "up" in space. You know? Heat rises? I therefore propose the use of fans. Imagine how fast the fans could spin in the vacume of space!!! They would be much more effective "up there" than down here with all this inefficient "atmosphere" crap. The fans could also redundantly double for propulsion when needed.
Why has NASA not thought of these things? NASA really ought to be hiring real geniuses like many of the other gifted
There used to be talk that the V. 34+ speeds of 33.6 kbps represented the very fastest that US phone lines could ever handle. It just wasn't scientifically possible to go any faster.
The 33.6 limit was NOT due to the phone lines, it was due to the equipment at the end of the phone lines at the telephone exchange.
At the telco end, telephone audio would be converted to and from analog and digital so that an analog signal could be presented to your phone, but on the other side a digital signal could become part of a digital packet switched network to efficiently be routed to where your phone call needed to go.
Upgrade that equipment or allow the elimination of conversion between analog and digital and you upgrade the limits. The limits of the copper lines themselves are much higher than 33.6kbit/s.
God, I cannot belive that guy kept his job.
I think God is the correct word here. Is it just me, or are those videos reminiscent of one of these crazy religious evangelists that we see on TV?
He is commanding the faithful it would seem. What a fucking wanker. "Give it up for me!"? I think maybe he should give up the jelly filled Krispy Kremes and go on a long term course of sedatives and psycho therapy.
I agree with what you have said here.
I'm still trying to understand how a collision technique, where the attacker has on control over what the hash will be, can be useful for injecting bogus data into a bittorrent or a similar modern p2p network?
Ah, I didn't say the act of finding a collision would be useful. Since it is impractical. What I am saying, is that the only option is an impractical one. In other words, not really feasible.
If you can exhaustively search for random data that gives the same hash, then that is useful because you can serve it as the original. But that if is a pretty huge if. ; )
Remember that those 2^69 "operations" (each many CPU cycles) are for a SHA1 "collision" attack. A "preimage" attack that would be necessary to inject corrupt data into a p2p network using SHA1 (such as Bittorrent) is much harder and has not been discovered and published.
Paul,
A pre-image attack is NOT what is needed to inject corrupt data into a p2p network which uses SHA1. The calculation of the preimage (besides usually being impossible) buys you nothing. Why would you tackle this beast of a problem head-on when the pre-image can simply be downloaded!? Yes, that's right, the file itself (or portions depending on how the hashing is done), IS the pre-image. Having the pre-image buys you nothing in creating alternate data with the same SHA1 hash, because what is needed is the convienience of being able to craft both the good and bogus data.
SHA1 is used in different ways. It can be used for authentication, whereby only the hash is compared and the pre-image is never stored. It can be used to authenticate a file where the file is seperated from the hash in such a way that both (mostly just the hash) cannot be altered. Or it can be used as a strong checksum for a file, in which case the hash is sent with the file or openly associated with the file, for the purpose of making sure data transfered correctly. With something like bittorrent, you're probably not going to be able to change the publically served hash in the torrent file along with that hash that the peers are aware of, so your only option is to find a collision.
If you can control the creation of both good data and bogus data, then you can do this against SHA1 in a much reduced but still very difficult process, thanks to the new found weakness. But if all you control is the creation of bogus data, then you are at the mercy of the full strength of SHA1.
Pre-image attacks have NOTHING to do with injecting bogus data into a hash protected P2P network. The pre-image is available to all. What you need do perform is a COLLISION attack.
Pre-image attacks are used when the pre-image or data/file is unknown. This is not the case with P2P. The pre-image can simply be downloaded. Confirmed pre-image attacks can be IMPOSSIBLE, because there are an infinite number of possible pre-images of varying sizes which will provide a collision or otherwise more than one possible pre-images of the same size as the real pre-image. There is no way to know which equivalent pre-image is the real pre-image unless the full fixed data space is searched and only one pre-image is found (this would require a pre-image of the same size or smaller than the hash size). The only way to be sure that you have the correct pre-image size, would be to preview the real pre-image, in which case there would be no point at all.
A hash algorithm takes an arbitrary number of input bits and generates a message digest of a fixed number of hash bits. Therefore, if your input data is larger than the hash data, then hashes have to be able to represent more than one input data set, because the hash is of a finite size.
They also claim that they can encode files which can be broken later. This is more feasible, since this requires the reduced collision attack. Of course, how feasible and practical is this really? I highly doubt they can deliver on this given the amount of data the music and movie industry will want protected and the whole 2^69 thing. ; )
This really sounds like snake oil to me.
the scientist there said that there are only 2 features: spotlight and something else. He stated that all other ones are pretty much nothing.
I realise you are kidding, but...
I am anxious to check out the new built in graphing functionality.
Systems like FreeBSD and SOlaris (at least on specific hardware) allow for going quite a bit beyond a chroot. Please look into it soemtime
/. to look into this stuff.
I didn't say OpenBSD was the best solution for this. You seem to be getting defensive now and reading way more into what I am writing. I am showing solutions which OpenBSD provides, without any claim of comparitive effectiveness. It's not like I came in and said Solaris containers or DSD are a waste of time since OpenBSD has chroot!
I find it pretty amusing that I'm being told on
You can just keep ignoring this and point at all good OpenBSD features, well, we agreed quite a few posts ago about their attitude and featureset.
I'm not trying to be a fanboy. I'm just stating things as I see them. I have not ignored anything. How many times do I have to say that OpenBSD is not perfect and does not always fit?
Maybe it is just me, but I end up very often eneding things (one thing in particular, see above) that OpenBSD does not supply.
I often choose something other than OpenBSD.
More recently I have found myself ending up using more and more SMP hardware, and while OpenBSD has become a valid option now on that in some cases, it is far from what I end up needing most often, for exactly that thing, an internet facing machine running some mix of services.
I wouldn't dare use OpenBSD for SMP in production at the moment. Nor would I use NetBSD or FreeBSD. If the only way to get acceptable performance to meet the needs was to go SMP, the it would typically be Solaris or Linux.
Do you not think this discussion has become a little ridiculous? My original point and all along, has been that I don't believe the other BSD's can just be brought up to the security which OpenBSD provides, WITH A LITTLE EFFORT. Now all of a sudden we're talking about Solaris on "specific hardware" or a specific area of FreeBSD? I have been talking about overall security all along and you pick weaker points in OpenBSD which are covered very well elsewhere and go to town on them. Yet I have said time and time again, that OpenBSD is not perfect and does not always fit well.
With a small amount of effort on Free or Net, you're going to get all the benefits of OpenBSD's ongoing audits, design stance and active mechanisms?
Absolutely, and those features are extremely usefull to tackle specific classes of attacks.
Yes specific classes, however very often exploited attacks.
Quite a few security breaches result from simple misconfigurations, and none of the mentioned mechanisms does much to prevent those while of course they do help prevent exploitation of a whole bunch of possible bugs that can result in privilege escalation, so there is a level of containment there.
I'm not talking about user mess ups though. I'm talking about OpenBSD. No matter what the OpenBSD team does, I don't think they could ever cater for the users who can't help but get themselves into trouble.
For services like a public dns, smtp and in many cases http, I prefer being able to seperate those from the host environment so that even in case of a local root compromise, the effect is still contained within an environment specifically built for that one service.
No problem, in fact Apache ran in chroot by default, as of OpenBSD 3.2, Nov 1st 2002. named chroot by default, as of OpenBSD 2.4, Dec 1st 1998 and smtpd was default chroot at least in 2000.
You use the word prefer as if you are choosing one over the other. Wouldn't you rather both to be sure? Especially if it comes like this as default?
For many a situation I found having to put in quite a bit of efford to make things secure and functionally what is desired (I have yet to find the customer who only needs a basic apache and smtp server), so a little extra efford while setting things up is not too much of a problem, esp. when it saves efford for maintenance later on.
Yes, life can be tough.
Ideally, you'd have all the openbsd security mechanisms together with what I just described and something like mandatory access control (having acl support makes live a lot easier and safer when running samba on an internal server for example)
Yes, I would like this.
As long as we can't have that, I'll have to make a choice, and I believe that choice is not as straightforward untill most peope only actually need a default install.
OpenBSD is an excellent choice as long as it at least can be configured to meet all needs. Obviously if it can't currently support a need then it must be overlooked. But this is a far cry from overlooking it just if the default configuration does not meet the needs. It's not like the default install is as functional as it gets. We all know that OpenBSD is quite the opposite.
...strength for general internet facing duties...
In my opinion, that is only true if what you need happens to fall within the focus of the OpenBSD team.
By those general duties, I am refering to the usual suspects: DNS, FTP, HTTP, POP3, SMTP, etc. W^X, Propolice and Stackghost tackle some pretty generic security problems which can plague these services and are responsible for a large percentage of successful attacks. However these are not the only services that OpenBSD supports and the active security mechanisms work regardless of the application being protected.
In other words, they are limited in what they offer, but when they offer something they do it well.
I agree. But don't forget that the original argument is regarding OpenBSD security (obviously of what it actually supports), not OpenBSD suitability for everything.
On another note, I find it interesting how you (tho in a friendly way) get somewhat defensive as soon as someone suggests there may be other and even better solutions then OpenBSD while at the same time agreeing that it is not perfect. I don't think there is any reason for this defensiveness, noone is saying it is bad or was attacking it in any way.
You are preceiving something which is not there. But this is not hard when we are just passing text to each other.
In my day to day work and personal life, I choose to mostly use NetBSD, OpenBSD, Mac OS X and Windows XP. When I get my hands on some nice dual-core Opterons, I will probably go back to FreeBSD for a lot of what I do at work. At the moment NetBSD is mostly what I use. I use OpenBSD for my servers and firewall/gateways, NetBSD for internal servers and workstations (R&D), OS X for my desktop work and XP because sometimes I have no other option.
I am not getting defensive. I just don't think getting NetBSD or FreeBSD up to par on the security OpenBSD provides can be done with a little added effort. By the same token, I don't think getting OpenBSD to perform as quickly as NetBSD can be done with a little added effort. Same deal when the dust settles on FreeBSD and dual-cores are the norm, although probably to a much greater extent.
However, there are also other platforms which implement security mechanisms, and at times ones that OpenBSD does not have.
I wouldn't deny that.
My point has been that there are many active security mechanisms built into OpenBSD, which take it beyond what is just easily configurable on other BSD's. Privilege Seperation work is one small part of the whole and it is very far from the strongest example. W^X, Propolice and Stackghost (sparc) are transparent, effective and cheap on system resources and come as part of the whole as default. You don't have to apply patches and recompile only to find lots of binaries no longer work or that the new mechanism itself has caused a remote root vulnerability.
I realise OpenBSD as it stands is not perfect, lacks some security mechanisms and is not always the best fit. But it seems to have the highest strength for general internet facing duties and is beyond taking another BSD and just adding a little extra effort to security.
In other words, this is a good reason to use openssh, but in itself not an argument for (or against) OpenBSD.
An operating system is more than just a kernel.
It was OpenBSD developers who developed OpenSSH and added priv sep functionality. OpenSSH is just one example of priv sep work done and ready to use in default OpenBSD installs and they continue to work in that area and many other security enhancing areas. That's my point. That they cover many areas with a focus on security and we now all have priv sep OpenSSH thanks to their efforts.
This is a single example application out of many, using a single example security mechanism out of many, which has been developed (the code, not the concept) on and primarily for OpenBSD by OpenBSD developers. And you think this is not an argument for OpenBSD when they have these skills and focus?
I just wanted to point out that privilege seperatiopn is not an operating system issue, it is an application issue,
My previous statement, "Yes but priv sep requires code changes for each privilege seperated application. Some apps are particularly difficult to do this with, like ssh.", does not refute that.
and for many relevant applications where OpenBSD has a default install with privilege seperation, you will find that other platforms have the same.
My original point, is that they roll out many security mechanisms and this is just one of them.
Yeah, we'll just have to content ourselves with our mere 64 bit Windows and Linux, and envy you cutting-edge Apple users with your 32 bit OS.
Just because an OS can be made to compile for 64bit, doesn't make it cutting edge if it slows down and you don't end up needing more than 32bit space.
OS X display functionality remains 32bit on purpose for performance reasons, for example. There is a lot to Apple's "cutting edge" OS that is irrelevant of whether it is 32bit or 64bit. 64bit doesn't just magically make an OS better if the OS is not going to be used to exploit the specific benefits that 64bit brings.
As far as I am concerned, the Tiger is the top of the line when it comes to cats. People keep refering to the Lion as "the king of the jungle", when in fact Lions mostly laze around in the plains, eat what their women catch and get a little bit of nookie every now and then only when their women want it.
Meanwhile, the Tiger rules the jungle as king, is much larger than pussy lions, has a real "lion heart" so to speak and would kick a lions arse any day.
Lions are over rated. I hope no newer releases of OS X will be called Lion, because Lions suck. I mean come on, they get chased away by hyenas! A tiger would never stand for that kinda shit, the hyenas would be desert.
Okay, now since we have established that the Tiger is indeed the king of the jungle and the master of his domain and as such, is "the top of the line in cats", I feel a newer line of naming is in order. I would like to suggest rodent names and would very much like to see the next version of Apple's OS X be:
Mac OS X Beaver, complete with yet another hairy box. I can already imagine the hairy desktop wallpaper I will use and can offer gigabytes of potential official Apple OS X Beaver wallpaper to Apple if they need it.
Firewall stealth mode.
"Stealth mode", with respect to firewalls, is little more than a marketing catch phrase. The biggest positive thing that it does do for users, is make them feel safer. I have detected my own "stealth mode" firewalled hosts easily with nmap and know of techniques to make it even easier to do if the "stealth" host is at least one router away.
--
People think George Bush is dumb because he's not articulate; just like Stephen Hawking.
Stephen Hawking has a motor neurone disease, meaning his difficulties are purely physical. George Bush on the other hand, does not, he is just a dumb shit. A dumb shit who continues in his daddies footsteps, killing innocent children.
Retard.
privilege seperation is a technique that can be employed on any Unix and is nowhere OpenBSD specific, their developers do use it where they can tho it seems.
Yes but priv sep requires code changes for each privilege seperated application. Some apps are particularly difficult to do this with, like ssh. But after a lot of effort, they did it. So there is a huge gap between "can be" and "is".
As I've said before, OpenBSD is not perfect (what is?). But it is still one of the best choices for security and continues to advance. It obviously is not going to fit into every need.
This is really 'more secure out-of-box', though, since a little effort with any *BSD will get you to the game point.
Which of the other BSD's has gone all out nuts with active protection mechanisms? None to the point of OpenBSD.
W^X, Propolice, Stackghost, priv sep, priv revocation, etc etc etc...
Not to mention the passive efforts such as the audits and wholesale migrations away from potentially dangerous code.
Sure it might not be perfect (what is?), but I don't see how anyone can claim that any other BSD can just be configured with a little effort to match OpenBSD's security. They specifically balance everything they do on security and true freedom. Teams of people working hard for years on such a specific area, yet you think it can easily be matched with a little effort with another BSD?
How often have you read an advisory against the BSD's, which stated "OpenBSD not vulnerable" and "OpenBSD fixed this x months ago"?
That implies he doesn't know much about BSD. Advocating Open as a first install then, might not be the best of ideas...
"Thrown into the deep end" mean anything to you?
Read OpenBSD documentation, use OpenBSD, repeat and persist until it is crystal clear. What better way to learn than to be confronted with problems, research them and conquer them?
I am not really impressed with NetBSD or FreeBSD documentation, especially compared with OpenBSD documentation. Do you advocate learning from a system that does more for you and explains less?
If someone asked me what the best way to learn linux is, I would suggest Linux From Scratch. After that, all the distros will probably look restrictive and broken to most people who got the most out of LFS.
they generally assume you will *not* be dual-booting.
Before the days of my house having tens of operational computers, I used to dual boot OpenBSD often. For a long while I had two Seagate 20GB disks which I was booting between OpenBSD, Debian GNU/Linux, Windows 2000, QNX, OpenBSD, FreeBSD, BeOS 5 PE and Windows NT 4.0. Yes, OpenBSD was on each disk. One was my main OS and the other I used for testing.
This was mostly for my learning. Smart Boot Manager is great!
I never could get Solaris 8 x86 or SCO UnixWare to play well with other operating systems on the same disk.
OpenBSD's Install is a nightmare for a new user
OpenBSD's installer might be a shock to a newbie who is used to typical Linux installers, or even FreeBSD or NetBSD. But I love it! It is fast, straight forward and functional. Just read the fine documentation and then enjoy it from then on.
I have been trying to install NetBSD 2.0 across multiple spindles and I can't seem to find a way to do it without loosing my disk configuration when moving on to the next disk. I resorted to installing on one disk, booting up from it and then creating the partition, slices and file systems manually, moving onto them what I wanted and then updating fstab. What a pain. OpenBSD deals with this no problem in the basic text installer. Trying this recently with NetBSD, I realised how spoiled I have been with OpenBSD.
The OpenBSD installer is anti-bloat all the way. I can install OpenBSD on a modern PC in about 3 minutes and OpenBSD with X in about 5. Sometimes after installing OpenBSD, simply typing "startx" brings X up without configuring it.
And once OpenBSD it is installed... pkg_add almost always works perfectly for every available package.
I can't for the life of me, figure out what you mean when you say the OpenBSD installer is aimed at the tin foil hat user? I love the fact that I can easily modify boot media to install from a console port. Why bother with graphical fluff when installation is just an occasional means to an end. It's not like you want to spend any great amount of time in an installer.
If I wanted to install a BSD on my little home router/gateway, just for the sake of playing around with BSD, which BSD is the one to cut your teeth on?
I moved to OpenBSD full time years ago after I discovered the high quality documentation (the man pages mostly). Sometimes when I need to use something other than OpenBSD I am reminded of how great their doco really is. Now there are also lots of great quality dead tree books too.
OpenBSD-specific books
For learning, I think good quality texts as a guide and reference and a clean consistent platform are important. So I would recommend OpenBSD for that. You should suffer much less frustration if you are willing to read and use OpenBSD.
For a firewall/gateway, OpenBSD is the native home of pf.
To dispose of the harddrive, you must physically destroy it, basically because the drives have gotten too smart.
Drives have been doing this for at least the past 10 years that I know of. My old WD Caviar and Maxtor 340MB drives did that around '94-'95.
This is the reason that hard drives suddenly started appearing on the market with seemingly no bad sectors to be marked by the file system to avoid. The days of seeing "B" blocks in Norton Disk Doctor and trying to "recover" them were mostly over. The truth was that there were bad sectors, but they were remapped to spares to make drives look good and help to guarantee minimum storage. Due to this, if you had a drive that did exhibit bad sectors, because the spares were all used up, then you had a really bad drive. I always took such drives back.
This is not new though.
Dead is boolean. You are either dead, or you are not dead. There is no "mostly dead" like in The Princess Bride. The closest you get is "almost dead", which we call dying. Attempts to call a hard drive which still works "dead" will be met with contempt by more reasonable people.
I have resurected disk images from hard drives which would not spin long enough to complete the task. You know when a drive starts that click - spin down - spin up - click - spin down, etc syndrome? As far as I am concerned, a drive such as that is dead. However, I have found that Ghost will happily wait for blocks to become available while I unplug the power from such a drive and plug it back in. I get non-corrupt Ghost images doing this multiple times until the process completes and I can restore the image to a good drive.
Would you call a drive that will run for no more than 2 minutes dead? I would. Yet I can image such a drive (before it decides to never spin up again).
As far as destroying a really busted drive goes, a caustic soda / water mixture poured into the hole under one of the "void if removed" stickers does wonders. ; )
"your 3000 grand monitors" 3000 grand? They're more expensive than I thought!
I thought he meant 3000 really nice monitors.