Freedesktop.org is doing a lot of work on a proper hardware abstraction layer to sit about the OS's and provide the services the GUI layer needs (Gnome, KDE, whoever).
The problem with hardware databases is the issues are frequently combinatorial. So you get bugs like
"PS/2 port with xyz touchpad and the IRQ is shared"
or
"Specific VIA mainboard and >1Gb of RAM and certain PCI devices"
or
"SCSI card A vanishes but only with this BIOS option and this other card present"
and thats the tip of the iceberg.
It isnt "10 mac configurations versus 10,000 PCs" its more like n^lots.
There are other things that make it more complicated - for example installing the Nvidia binary drivers might make you an accessory to a copyright license and patent violation (remember IBM has granted the RCU and other patents for *GPL* use....). There are probably ways to deal with that and keep lawyers happy.
As far as the programs go, kudzu is built on top of pretty portable detection libraries that should be entirely reusable. A lot of the detection has also moved into general upstream kernel handling now that modules has PCI identifier tables. That means the intelligence for a lot of PCI driver loading is now outside vendor tools and extensible.
I'm all for a bottom end free-software cross vendor library to do the work.
Anyone can get ripped off at any level. The good thing is that someone at least *noticed* this one and is now beating restitution out of the victims.
It can happen at any level in government or business (although its a government speciality since its not their money). State level, "Oracle v California" anyone ?
The VIA C3 problem didn't get caught because it worked in the betas. The bug involved is in all the 2.6.x kernels but depends on the alignment and size of the kernel. While the beta kernel worked the final kernel didnt get lucky.
Ingo and others are currently working through this one to try and find the cause. At the moment nobody is sure if it is a Linux bug or a CPU errata being tripped.
In the UK at least the police would have quite a list of things to charge the virus writer with. The coastguard and microsoft might also have liabilities.
As with most of the EU you cannot disclaim liability for death and some forms of injury, whatever you write on the license. (Nowdays "Not verified for use in safety critical systems" seems to have become an accepted way of ensuring the liability lands on the user though).
Considering the car analogy
You can be liable if you make a car with dodgy brakes (unsuitable product, forseeable that it will cause an accident) You can be liable if you knowingly drive a car with bad brakes (because its forseeable that this will cause an accident) and you are most definitely going to get into trouble if you empty a bucket of oil over the road surface (aka writing the worm)
Its all very well talking about elegance and planning in advance until you try and deal with hardware. No amount of zen contemplation of your code is going to tell you what a debugger does about how the hardware and its documentation relate.
The neatest debugging tricks I've seen so far are those logging all inputs and returns from the OS level. Since you can replay them you can rerun the app to an earlier point and investigate - in effect you can run it backwards from a bug to see how it got there.
Except that it seems "Solaris maybe, especially if we can knock Red Hat, Java unlikely even though its creator gets it".
Sun need to keep a tight rein on the java name, and maybe the standard process. You want it to be called Java, you make it pass the test suite. That bit makes sense, although its hard to take too seriously given all the things out there like vnc java versiosn "patched to work with macos", "patched to work with ie5" etc.
What matters is that a JVM+class library called "Java" or "J2EE" etc behave in the defined way. Just as "Posix" and "LSB" matter. Implementation, reference code, no reason that can't be truely open.
In the Sun case the fact some of the interface specs are secret for tests for some of the extensions is not umm helpful. Imagine C++ programming where you had to sign an NDA to open a file 8)
Its easy if you do it carefully and you know the couple of gotchas - in fact I did one of the ftp.linux.org.uk boxes a couple of days ago *while* it was serving fedora isos at high load
Grab the yum package and fedora-release Install these two
Now (works around a missing dependancy that might otherwise bite people)
yum upgrade e2fstools krb5-libs yum upgrade rpm # You want the newer rpm early yum upgrade
and it should just work.
No guarantees but its working fine for me. Getting to FC2test3 is best done by CD. I'm going to play with yum updates once FC2 is out but things like the Xorg config file changeover make it hairier
I'll second that here too. Red Hat Enteprise Linux is a package not just a pile of bits. Its a support and service arrangement, qualification, support and all the stuff that goes with it.
I don't think anyone has any problems with white box. If you want conservative and you don't want any support or guarantees then it may well fit better than Fedora.
I think for the average hacker however RHEL3 and White Box are not going to appeal that much, because they are older software - that people are sure works or know the limits of - and not the latest and greatest. No SVG themed gnome 2.6, no current KDE, no 2.6 kernel...
While there doesn't appear to be any caselaw handy there is a consensus view that it falls under the "duty of care" an employer has to their employees. That isn't a disaster since the law revolves around the ficticious "reasonable person" so it requires reasonable effort rather than perfection.
Similarly although case-law has yet to appear there are good arguments that someone failing to take reasonable care of their systems and getting viruses/being used to spam others could be liable for negligence.
"for every right there is a duty" is the basis of a lot of UK law
Also note that you can stick an FC1 or FC2 test CD into an RH9 box and upgrade it. You can also live upgrade RH9 to Fedora Core if you like living dangerously
Hand install:
fedora-release
yum
yum update rpm
Hand update krb5_libs and e2fsprogs carefully
yum update
and go read a book.
[This isnt an approved official way to do it but it seems to work!]
Yum is also included. I've found yum a lot more useful than up2date.
Re:Great news, but..
on
JOE Hits 3.0
·
· Score: 5, Interesting
I for one use joe. It does what I need and it does it fast. More to the point I suspect it uses the same keystrokes I learned back in prehistory (before DOS!) from VDE and Wordstar on CP/M.
The MD5 auth hack unfortunately fixes only some of the issues here. There is a second way to disrupt streams involving shrinking the MTU to a stupid level, and the "aim for the window" tricks observed in the other attack apply here too.
Going back to 199x it was known that you could hit long lasting streams with ICMP must-fragment mtu = 80 and similar values and basically stall the stream. Some stacks correctly turn off MTU discovery faced with such a claim others ignore it (and break on low mtu links), and others believe it (and break spectacularly). The routters in the middle of the stream have no knowledge of the MD5 or other secrets so can only reply in untrusted form. It is possible to do some checking from the reply data but not full checks.
To make it more fun the proposed fix seems to open a new exploit path that may be worse. Fortunately there is a trivial fix for this case if the problem is confirmed real.
The ultimate problem though is ISPs not filtering packet source addresses. If the governments want to pass one sane bit of 'cybersecurity' law then filtering end users to stop source address spoofing would be it, and require they only used their legitimate assigned addresses (or other addresses properly owned by one way downlinks like satellite etc)
Actually I prefer the war on porn.. with no porn who is going to fund all the evil DRM projects 8)
Two simple targets
on
Red Hat Recap
·
· Score: 5, Insightful
Fedora - this is what RH was before it got tangled up in retail and other things that slowed it down. Its regular releases, new toys and akin to RH5, RH6, RH7, etc
RHEL - business oriented product with Red Hat support and with certifications and testing guarantees for things like Oracle. In order to b e supportable it handles less hardware, contains less packages and picks more conserative ones, as well as having a long lifetime.
I've not found many businesses have problems untangling this. but some of the non business folks got a little baffled or still don't realise that a) FC1 updates RH9 fine b) FC is exactly what old RHL (7.x etc) was about.
Re:At a loss....
on
Red Hat Recap
·
· Score: 4, Informative
If Red Hat support isnt worth $179 then don't buy RHEL, its as simple as that. You can grab Debian, Gentoo, RHEL clones like Whtiebox, or use Fedora.
Thats why the MS comment is so off, you have lots of choices. In fact I believe Progeny were also talking about RH9 extended support, and there is a Fedora legacy project. Probably the support quality of the volunteer projects won't be as good as RHEL or SuSE enterprise products, but there is a reason for that you can copy code for free, but support and errata testing cost real money.
As to updates. FC1 will update RH9 smoothly.
Alan
Re:If you've ever wondered why your PHB...
on
Why PHBs Fear Linux
·
· Score: 2, Interesting
I'm still doing my MBA and actually Linux shows up in one of the corporate strategy case studies as a direct study item. Sadly the lecturer decided it would be unfair to set a question on that study;)
On our course I've seen little "pro-windows" save the choice of OS the university made for desktops. Some of the lecturers including the economics lecturer find aspects of the GPL model fascinating.
Absolutely - look at "Java Desktop" (aka 'Linux', 'Gnome') for an example. Many projects go as far as to ask that you rename any forks to avoid confusion.
At the end of the day these guys are not selling MythTV. They are selling an appliance. It happens to run MythTV and come with an ISO including the sources (now..), but to most users its a box that records tv programs.
I seem to remember that being done for Red Hat 8, making them fit together isnt that hard now days, and all the joint work KDE and GNOME people have been doing at freedesktop.org on common specifications helps even more.
Its the peanut gallery who seem wedded to the 'gnome v kde war'
Microsoft do all their development internally so the security situation is different. Internal control in MS does not appear to be reliable given the number of large easter eggs that appear in applications. If someone can sneak a mini-flight sim into an app then they can sneak other stuff in.
Slashdot Mirror
Freedesktop.org is doing a lot of work on a proper hardware abstraction layer to sit about the OS's and provide the services the GUI layer needs (Gnome, KDE, whoever).
The problem with hardware databases is the issues are frequently combinatorial. So you get bugs like
"PS/2 port with xyz touchpad and the IRQ is shared"
or
"Specific VIA mainboard and >1Gb of RAM and certain PCI devices"
or
"SCSI card A vanishes but only with this BIOS option and this other card present"
and thats the tip of the iceberg.
It isnt "10 mac configurations versus 10,000 PCs" its more like n^lots.
There are other things that make it more complicated - for example installing the Nvidia binary drivers might make you an accessory to a copyright license and patent violation (remember IBM has granted the RCU and other patents for *GPL* use....). There are probably ways to deal with that and keep lawyers happy.
As far as the programs go, kudzu is built on top of pretty portable detection libraries that should be entirely reusable. A lot of the detection has also moved into general upstream kernel handling now that modules has PCI identifier tables. That means the intelligence for a lot of PCI driver loading is now outside vendor tools and extensible.
I'm all for a bottom end free-software cross vendor library to do the work.
Anyone can get ripped off at any level. The good thing is that someone at least *noticed* this one and is now beating restitution out of the victims.
It can happen at any level in government or business (although its a government speciality since its not their money). State level, "Oracle v California" anyone ?
The VIA C3 problem didn't get caught because it worked in the betas. The bug involved is in all the 2.6.x kernels but depends on the alignment and size of the kernel. While the beta kernel worked the final kernel didnt get lucky.
Ingo and others are currently working through this one to try and find the cause. At the moment nobody is sure if it is a Linux bug or a CPU errata being tripped.
In the UK at least the police would have quite a list of things to charge the virus writer with. The coastguard and microsoft might also have liabilities.
As with most of the EU you cannot disclaim liability for death and some forms of injury, whatever you write on the license. (Nowdays "Not verified for use in safety critical systems" seems to have become an accepted way of ensuring the liability lands on the user though).
Considering the car analogy
You can be liable if you make a car with dodgy
brakes (unsuitable product, forseeable that it will cause an accident)
You can be liable if you knowingly drive a car with bad brakes (because its forseeable that this will cause an accident)
and you are most definitely going to get into trouble if you empty a bucket of oil over the road surface (aka writing the worm)
Its all very well talking about elegance and planning in advance until you try and deal with hardware. No amount of zen contemplation of your code is going to tell you what a debugger does about how the hardware and its documentation relate.
The neatest debugging tricks I've seen so far are those logging all inputs and returns from the OS level. Since you can replay them you can rerun the app to an earlier point and investigate - in effect you can run it backwards from a bug to see how it got there.
Except that it seems "Solaris maybe, especially if we can knock Red Hat, Java unlikely even though its creator gets it".
Sun need to keep a tight rein on the java name, and maybe the standard process. You want it to be called Java, you make it pass the test suite. That bit makes sense, although its hard to take too seriously given all the things out there like vnc java versiosn "patched to work with macos", "patched to work with ie5" etc.
What matters is that a JVM+class library called "Java" or "J2EE" etc behave in the defined way. Just as "Posix" and "LSB" matter. Implementation, reference code, no reason that can't be truely open.
In the Sun case the fact some of the interface specs are secret for tests for some of the extensions is not umm helpful. Imagine C++ programming where you had to sign an NDA to open a file 8)
Its easy if you do it carefully and you know the couple of gotchas - in fact I did one of the ftp.linux.org.uk boxes a couple of days ago *while* it was serving fedora isos at high load
Grab the yum package and fedora-release
Install these two
Now (works around a missing dependancy that might otherwise bite people)
yum upgrade e2fstools krb5-libs
yum upgrade rpm
# You want the newer rpm early
yum upgrade
and it should just work.
No guarantees but its working fine for me. Getting to FC2test3 is best done by CD. I'm going to play with yum updates once FC2 is out but things like the Xorg config file changeover make it hairier
I'll second that here too. Red Hat Enteprise Linux is a package not just a pile of bits. Its a support and service arrangement, qualification, support and all the stuff that goes with it.
...
I don't think anyone has any problems with white box. If you want conservative and you don't want any support or guarantees then it may well fit better than Fedora.
I think for the average hacker however RHEL3 and White Box are not going to appeal that much, because they are older software - that people are sure works or know the limits of - and not the latest and greatest. No SVG themed gnome 2.6, no current KDE, no 2.6 kernel
It seems to help. And the more people who send them their own junk back in their envelopes with "no thanks" written on it the better.
While there doesn't appear to be any caselaw handy there is a consensus view that it falls under the "duty of care" an employer has to their employees. That isn't a disaster since the law revolves around the ficticious "reasonable person" so it requires reasonable effort rather than perfection.
Similarly although case-law has yet to appear there are good arguments that someone failing to take reasonable care of their systems and getting viruses/being used to spam others could be liable for negligence.
"for every right there is a duty" is the basis of a lot of UK law
Also note that you can stick an FC1 or FC2 test CD into an RH9 box and upgrade it. You can also live upgrade RH9 to Fedora Core if you like living dangerously
Hand install:
fedora-release
yum
yum update rpm
Hand update krb5_libs and e2fsprogs carefully
yum update
and go read a book.
[This isnt an approved official way to do it but it seems to work!]
Yum is also included. I've found yum a lot more useful than up2date.
I for one use joe. It does what I need and it does it fast. More to the point I suspect it uses the same keystrokes I learned back in prehistory (before DOS!) from VDE and Wordstar on CP/M.
Joe 3 will be most welcome here.
The MD5 auth hack unfortunately fixes only some of the issues here. There is a second way to disrupt streams involving shrinking the MTU to a stupid level, and the "aim for the window" tricks observed in the other attack apply here too.
Going back to 199x it was known that you could hit long lasting streams with ICMP must-fragment mtu = 80 and similar values and basically stall the stream. Some stacks correctly turn off MTU discovery faced with such a claim others ignore it (and break on low mtu links), and others believe it (and break spectacularly). The routters in the middle of the stream have no knowledge of the MD5 or other secrets so can only reply in untrusted form. It is possible to do some checking from the reply data but not full checks.
To make it more fun the proposed fix seems to open a new exploit path that may be worse. Fortunately there is a trivial fix for this case if the problem is confirmed real.
The ultimate problem though is ISPs not filtering packet source addresses. If the governments want to pass one sane bit of 'cybersecurity' law then filtering end users to stop source address spoofing would be it, and require they only used their legitimate assigned addresses (or other addresses properly owned by one way downlinks like satellite etc)
Alan
Actually I prefer the war on porn.. with no porn who is going to fund all the evil DRM projects 8)
Fedora - this is what RH was before it got tangled up in retail and other things that slowed it down. Its regular releases, new toys and akin to RH5, RH6, RH7, etc
RHEL - business oriented product with Red Hat support and with certifications and testing guarantees for things like Oracle. In order to b e supportable it handles less hardware, contains less packages and picks more conserative ones, as well as having a long lifetime.
I've not found many businesses have problems untangling this. but some of the non business folks got a little baffled or still don't realise that
a) FC1 updates RH9 fine
b) FC is exactly what old RHL (7.x etc) was about.
If Red Hat support isnt worth $179 then don't buy RHEL, its as simple as that. You can grab Debian, Gentoo, RHEL clones like Whtiebox, or use Fedora.
Thats why the MS comment is so off, you have lots of choices. In fact I believe Progeny were also talking about RH9 extended support, and there is a Fedora legacy project. Probably the support quality of the volunteer projects won't be as good as RHEL or SuSE enterprise products, but there is a reason for that you can copy code for free, but support and errata testing cost real money.
As to updates. FC1 will update RH9 smoothly.
Alan
I'm still doing my MBA and actually Linux shows up in one of the corporate strategy case studies as a direct study item. Sadly the lecturer decided it would be unfair to set a question on that study ;)
On our course I've seen little "pro-windows" save the choice of OS the university made for desktops. Some of the lecturers including the economics lecturer find aspects of the GPL model fascinating.
Alan
Absolutely - look at "Java Desktop" (aka 'Linux', 'Gnome') for an example. Many projects go as far as to ask that you rename any forks to avoid confusion.
At the end of the day these guys are not selling MythTV. They are selling an appliance. It happens to run MythTV and come with an ISO including the sources (now..), but to most users its a box that records tv programs.
Patent lawyer, military weapons specialist, president ?
I do know. I think I may even have been the first person to post a good explanation of how to sniff switched networks to bugtraq in fact 8)
There was arp monitoring stuff running too
Its also on a seperate switched port 8)
I seem to remember that being done for Red Hat 8, making them fit together isnt that hard now days, and all the joint work KDE and GNOME people have been doing at freedesktop.org on common specifications helps even more.
Its the peanut gallery who seem wedded to the 'gnome v kde war'
Microsoft do all their development internally so the security situation is different. Internal control in MS does not appear to be reliable given the number of large easter eggs that appear in applications. If someone can sneak a mini-flight sim into an app then they can sneak other stuff in.
More info will appear as the forensics are done.
But to emphasize: cvs.gnome.org is a seperate system