While you won't get much argument on attitude, back when I was searching for a resolver library to hack into a project, I looked at tinydns and downloaded it and started poking around for a license (since this was for work)- I didn't find one at all- and after the qmail license debacle, I thought it'd be a good thing[tm] to ask DJB what terms the stuff was licensed under. I got back a "There is no license, I don't believe in software licensing." reply.
So, if you're out of technical arguments and are down to social ones, considering BIND is the Sendmail of the 90's and Weitse hasn't attacked DNS as a project I think you're out of wind.
Look at the code, don't rush to judgement. Look at BIND's code. Compare and contrast.
I actually *like* BIND, but running it is always scary, even chrooted.
2. "When it comes to things like my medical records, or bank statements, then I think I'd like them kept obscure"
I'd rather have mine kept secure. You seem to be mixing the two. Obscuring your records by XORing them and posting them to USENET probably won't give you the desired result.
3. NSA also doesn't give KG-84's, KY-71's or whatever they're using this year out to anyone who wants one, that gives them a decisive edge in this case (though I've always wondered why the physical boxes themselves were always security-rated lower than the information flowing through them.)
This story has a lot to do with security through obscurity, since "normal" bugs don't get this treatment, just security bugs.
Maybe you should re-evaluate the meaning of the term "security through obscurity", as you seem to be missing it.
There's _already_ a project that's most of the way to B-level functionality. It's at http://www.rsbac.de/ and it already works.
I think we should question the use of our tax dollars to reinvent this wheel when there's an active *FREE* implementation already most of the way done that doesn't use patented technology.
Microsoft handed these out at a conference one of my cow-orkers went to. He charitably donated them to science- erm, that is *my* specific experiment-
Take one MS action figure: Duct tape to the end of a Nerf[tm] arrow. Place wadding in other end of Nerf[tm] arrow. Place C5-6 rocket engine after wadding. Launch action figure above paved surface.
Unfortunately, they're not as destructable as Kenny was (Dammit! Me Bastard! I killed Kenny!)
They're not as aerodynamic either, Kenny got a good 1000', the MS guy couldn't go over about 600.
Next time the MS dude is gonna ride near the engine, in fact I'm considering rubber-banding them all around the fins with their heads in the blast area. Just gotta find some nose weight.
The problem is that there isn't a great pull for manufacturers to write to UDI. Most of them likely see "unsupported" OS' as a drain on their support resources, and that's a problem that needs to be fixed. It'd be nice to see RH or VA take some of that IPO money and start working on the problem. A driver support division somewhere with funding that could gain some mindshare would be cool, especially if it were non-proprietary.
FWIW, AIX ran on System/370 systems well over a decade ago, it never sold well. Try a search for AIX/370.
It's mostly sendmail compatible, faster than most other MTAs, easy to configure, designed to be secure, and doesn't have the interaction problems that qmail sometimes does with other software. Sendmail is still the most flexible MTA on the planet, and for some people running legacy system gateways, there isn't a good alternative.
It's also easy for vendors to add sendmail (or postfix) to their OS distributions, qmail's license isn't favorable to 3rd parties.
Sendmail is the best "lowest common denominator" MTA. Postfix's sendmail compatibility program attempts to provide the base functionality necessary for _most_ external programs to work. Qmail doesn't even pretend to try to be sendmail compatible. Some people think that's an advantage, others don't. Because sendmail is monolithic, it can do things easily that modular mailers like qmail and postfix can't.
IBM's never been shy about releasing documentation and architecture reference manuals from the early 360 days through the 390 days.
On the other front, moving from running under VM to running without VM isn't _that_ difficult since IBM's VM looks a heck of a lot like the real hardware (surprise!) You'd probably need to port the SVC tables or perhaps provide most of the ones that fall under "OS Simulation Services" for VM (the ones like SVC 93/94 that the TPUT macros use.)
As far as running under VM (which a native version would be able to do as well)- the thing to get excited about is being able to host Linux applications without changing environments, and indeed writing collaberative applications to talk to other VMs. That gives you a signifcant software base for the S/390 that doesn't need to be supported seperately. So, you could run a mail system, USENET, or even hand out shell prompts and not take anything more than some CPU and I/O.
It also may give IBM some extra hardware for porting projects that can run batch compiles and things pretty quickly. If the port is done well enough, it may give IBM a good internal development platform. Now all they need is a good cross-compiler for i386.
You're wrong about "go fast." A 747 at max throttle can outpace the stealth aircraft. Going fast generates too much of a heat signature and makes them less stealthy.
As has been pointed out, the GPL is a license, and as a minor you can't agree to a license because that's entering into a contract. Minors can't do that in most countries. Corel isn't saying minors can't use Linux, they're saying they can't download it. If you invalidate this, you invalidate the GPL as a contract. Either the law needs to change on contracts, EULA's need to be struck down as invalid (whoops, there goes the GPL!), or you need to have mommy or daddy download the software for you.
As has also been pointed out, you can just go ahead and download the software yourself if you're a minor. You'll have an "illegal" copy and the GPL will still be enforcable and apply to your copy. Seems to me that this is the best solution given the current set of laws.
Corel and their legal department aren't at fault here. Instead of a sensationalist post about Corel, this should really have been about the state of the judiciary. Corel's lawyers have done the best they could given the parameters they have to operate in.
A more troubling question is if the minors who've contributed code can even license it at all without their parent's consent.
Ultra 2's are very fat pizza boxes and U5s are kinda fat pizza boxes. I've yet to see a mini tower Ultra outside of the Enterprise stuff that's tardis-like.
The newest Netra series are 1U high rack-mount pizza boxes - they look to rock too, especially for colo space where size is money. They're a cool charcoal color too.
SGI had a lot of early high-end Web business with the Challenge S, but Sun came in and spanked them, especially on the software side.
Probably the main failing of the Visual Workstation line is that it was too early. The lifetime on older workstations is a lot higher than on PCs, and I don't think SGI had the line funded to go out on much shorter than a PC cycle.
What do you think of the possibility of fall-out lawsuits from harmed companies, and class-actions on behalf of consumers will be (a) if the DOJ case goes to decision, and (b) if it's settled?
Is there any compelling reason for Microsoft to worry about similar suits in other countries? Has there traditionally been a follow-on of suits in non-US courts when a company such as IBM was found to be abusing a monopoly status?
What are the chances for the DOJ to settle given the fact that litigating the case fully will set precident? Do you agree or disagree with the premise that it should be litigated rather than settled to provide precident?
For anyone who can't get it to Babel, basicly they're contributing funding to improve the interface, develop for multiple OSen and add capability to mail clients to use it. Also, it seems this is an initial investment, not just a one-time thing.
This is amazingly cool. A government that is going to support Open Source security tools as an end in itself due to transparency of the source, reliability and I'd assume economic benifits as well.
I'd expect that as a student, you'd get some sort of "fair use" protection, just as I'd expect an underground "student publication" to. You'll want to read up on trademark/fair use stuff, or try to find a lawyer who'll give you an idea of the applicablility of fair use. The fact that they're not even questioning the content of the site would make me wonder seriously about it. If a student can't use their University's name, then what value is that affiliation? I'd also go to the local campus newspaper and start trying to get them interested in a story. If you can find a friendly lawyer who thinks you've got a fair use exemption, then have them send an answering letter to the University. You may also want to make sure it's perfectly clear on the main page that the site isn't affiliated with the University and that they own the trademark. It's easier to win if you can prove that there's no dilution of their mark. Their case will probably be about dilution, focus on that, not on just using the name. Also, use disclaimers in any mail you send from the domain.
Talk to a lawyer if at all possible, and try the "Dear University, I feel my site is covered by fair use doctrine, however I've added strong language to the disclaimer on my site to protect you from dissolution of your mark. If you'd like the text of the language changed, I'd be happy to work with you to come up with mutually agreeable verbage." Watch how it's worded though, you don't want to admit an infringement, just that you want to reach an agreement without giving up your domain.
I wonder if this is the end of the US-based domination of the World's software? Korea seems to have decided that Microsoft is strategicly bad to deal with and that Linux is a better choice. I'm pretty sure I've read that Mexico's school system is going to Linux.
The big question is "Unless the Linux-on-the-desktop crowd are significantly successful soon, will it mean that the clue-per-person index will go up in 'developing countries' while it's declining in 'developed countries?'"
The US Government's policies and strategies seem to be tilted towards commercial entities, not the efforts of the population at large (e.g. crypto binaries ok, crypto source bad) - countries with less disposable income in their populations are taking national strategic advantage of free (as in beer), and that could have serious long-term impact on the global computing environment.
More clue is good. I'm just worried that a lot of US and European policy-makers are buying into the less-skilled workplace being good and long term it seems to be a less-than-ideal solution.
With IPSec starting to gain some momentum as well as the current VPN craze (which seems to ignore the traditional encryption boundary issue completely), do you see a role in the testing and certification of vendor implementations to include checksumming of binary-only closed-source products and services?
Given that we'll soon see more Voice over IP, and we're currently seeing IPSec in routers, is there any other way the international community can be sure that a particular implementation hasn't been (legally or illegally) trojaned by a manufacturer or that they can gain a high level of trust in their vendors' implementation?
Basicly the USG is arguing in Bernstein's case that because there's an off chance they'll modify the export regulations, the case should be delayed. He's pointed out that they've said this before (when the export regs. moved to commerce), and it didn't happen.
What really needs to happen is that the full court needs to uphold the decision that software source code is covered by 1st ammendment protection. Then no matter what, it can't be legislated against. That's much more important than the government simply changing its export stance temporarily.
Linux/Unix isn't "virus proof" by design. Viruses are more difficult to spread, but it's possible- *especially* these days with less-sophisticated administrators and more frequently updated software. It's fortunate that we don't have anything more than a handful of concept viruses.
Trojan horses are more worrying than viruses though. It is possible to secure Linux from both threats, but that makes administration more difficult, and may mean not using stock kernels.
OS400 only runs on AS/400s, which are a different market than PC or Server-class machines. There's not a direct conflict, but it could be construed as one if AS/400 sales fall due to over-advocacy in another division.
Exactly what "Linux security measures" are you concerned about? How far are you willing to go to secure a Linux system yourself? If you're interested in significant security, check out http://www.rsbac.de/ Most Linux systems that are insecure are that way because nobody's taken the time to secure them. Good or bad, it's a mostly solvable problem. RSBAC places even more security oppertunities on the table.
I worked for somewhere that had GRiD Compasses and GRiD Cases in a past life. We had quite a few of them, and they all ran DOS. If you drop it on a corner, you'll break the plasma screen (we broke a few like that, but give our "normal" treatment they were amazingly rugged.)
The was a TEMPEST rated version, and in fact I had one of each that I kept in the trunk of my car. I actually came across a power brick for one of these last time I moved. My "rationale" for one of each was that I had to be able to "test programs on the TEMPEST version as well." I guess management's clue level over the years hasn't changed much;)
The TEMPEST ones also had a pretty cool encryption option. Bubble memory helped with not having to rely on magnetic media as well. The only problem with the Crypto option was that you weren't allowed to leave them in the trunk of your car:)
GRiD used to run over them with jeeps and drop them from helicopters in sales demos back then. Nothing else would stand up to it.
I think I seriously hurt the TEMPEST version of a Compaq Luggable that I had in for testing once. The GRiD's would take a heck of a lot more abuse.
New GRiDs were somwhere between $17,000 and $27,000 if I recall correctly. CryptoGRiDs might have been more.
GRiDCase's had better and bigger screens than the Compass, but weren't TEMPESTable AIR.
Point (A) said "spoofing in general" for the reason that there was a lot of more 'academic' discussion going on than discussion limited to the particular case in point...
> Very wrong. If you've followed bugtraq the last > week or so, you would've noticed the "bug" in > the linux 2.2 kernel that makes blindspoofing > easy on a network with little lag. On the...
Once again, as the attacker you get to pick what's spoofed. Spoofing from a blackholed network or from an easily-flooded host removes the lag issue completely. Synched clocks only work for similar implementations that derrive their sequence numbers from the time.
> Any recent tcpip implementation should should > have difficult to predict sequence numbers. I > don't know how older systems works, so you're > probably right.
"Should" and "do" are two different things. Making difficult sequence numbers affects TCP performance. At least for relatively recent versions of HP/UX you have to sysctl hard numbers, and the default was easily guessable. If you've a decent collection of hardware you can run nmap or ISS and look at the predictability of your hosts.
> I have a tendency to believe that most > core-routers are well-configured. Of > course, there are extreme amounts of poorly > administered routers... but are > there extreme amounts of poorly administred > core-routers?
(a) a leaf router will do quite well in this instance and (b) it only takes one, extreme ammounts don't mean much. Some tier-1's manage their routers well, and some manage them poorly..au doesn't have a great ammount of off-continent bandwidth (though it's certainly better than it used to be) so you'd probably be looking for on on-continent routing hole at either end if you were preparing an attack. (limted bandwidth tends to be managed better than widely available bandwidth)
I think it's an injustice to lump information warfare in with "traditional" NBC-type warefare.
The problems of INFOSEC today are the infrastructure of tomorrow. Power grids, water treatment plants, telecommunications infrastructure, etc. are all quite vulnerable in at least several instances. Don't forget that it doesn't take an anonymous long-distance attack to get "in." A virus on a demo CD, a trojan in an executable "greeting card", etc. Timebombed code can be left by a temporary employee, cleaning person with physical access...
Today, employers, even those who are running critical infrastructure are hard-pressed to not give employees Web access (401k plans, health insurance plans and others are starting to _mandate_ it) Most of those employees are on inseucre, poorly administered, untrusted desktop operating systems. Add SSL and VPNs to make tunneling next-to-impossible to detect and you've got a recepie for serious electronic mayhem.
The barrier to entry here isn't very high. If you look at the number of viruses and compromised hosts on the Internet, and see if you can get hold of the statistics for telephone fraud that relate to compromised PBX's. You'll see that the knowlege is already fairly easy to gain. It's fairly easily transferable too. But *there's no need to transfer it*. Recruiting people who are already good at it should be trivial for most either well-funded organizations or organizations with a strong "appeal" to either a targeted individual, or a member of the target's preferred sex group. Ideologies tend to be better draws, but it wouldn't be difficult in either case, nor would extraction of several unwilling potential accomplices. One sympathetic organization member with competence would probably have a trivial time recruiting as well.
Some of the people who have the skillsets aren't socially very far evolved, don't necessarily have access to material things they'd like and are under age. All of those groups are easily targeted.
It's all software and easily gained knowlege, and testing is trivial and not necessarily dangerous. Unlike most traditional weapons, it's fairly simple to test out information attacks without anyone detecting it because you can do it on your own systems.
Until infrastructure vendors start making secure-by-default infrastructure (switches and hubs predominantly) and it becomes widespread in the install base, things like hospitals, power plants, water and waste treatment facilities, telephone exchanges, banks, etc. will be good targets of oppertunity.
While some places practice good security, not all do. It's becomming quite trivial to place a small 2" square machine onto a LAN port. Wireless networking on the back side and you're in. For less than USD$1000 you could build such systems and disguise them as appliances like lamps.
Not many places outside of the national security arena even do RF sweeps. Infrared is starting to make even that less useful.
Look at what the failed S&L industry cost, it's possible to disrupt commerce in key segments enough to cause millions of dollars of damage today, and billions over the next 5-10 years, not all electronic terrorism need be traditonal warfare, economic warfare is just as valid.
We're "used" to terrorists who directly cause terror, now we're building the capability for them to set events in motion that have longer-term effects and aren't first-order effects.
Finally, the combination of electronic and unconventional warfare, since they need not be exclusive, is a new one. False SNMP trap, compromised phone switch and a ready to deploy "customer engineer" is just one example that springs immediately to mind.
I could go on and on, but that's probably enough for now.
> and since that is next-to-impossible to > accomplish on the net (due to lag, and pretty > random numbers used in the handshakes) -- we can > pretty much rule that out.
(A) You're missing the fact that TCP isn't the only protocol you can blindly spoof. So, if we're talking about spoofing in general, there's a UDP and ICMP-sized hole there waiting for poorly written applications.
(B) Lag has _nothing_ to do with a blind spoof attack, since you can either flood the spoofee or pick a host that's behind a network that doesn't report unreachables.
(C) Very diffuclt to predict sequence numbers are a relatively new occurance. I wouldn't bet my hard-earned money on everything using them either.
(D) Why are you ok with cracked end-boxes, but not anything cracked in the path? You wouldn't believe the number of poorly administered routers, older routers with vulnerabilities, and new Web browser configuarble routers set up by morons.
Your conclusion is probably correct, but your premises are flawed.
> You've got to get packets back to yourself, to > get to know what ports are open. In other words > -- it's not that easy. You've got to be "in > between" so that you can packetsniff the packets > coming from the host you're scanning, and the > address you've spoofed. > > (correct me if i'm wrong)
What's often overlooked is that 'in between' can be *either* in between the scanner and the victim or the victim and the spoofee. If you do the second part, it's more likely that you'll have a case of denyability if you're also the spoofee if you can route the replies to the spoofed packets out-of-band.
"We were sniffing our network that day because we seemed to be under some sort of attack, here're the logs and you can see that we didn't send any traffic out, it must have been spoofed" is possibly a good defense in such situations, especially if the spoofee is say a college network with a significant number of hosts and shared media.
Slashdot Mirror
While you won't get much argument on attitude, back when I was searching for a resolver library to hack into a project, I looked at tinydns and downloaded it and started poking around for a license (since this was for work)- I didn't find one at all- and after the qmail license debacle, I thought it'd be a good thing[tm] to ask DJB what terms the stuff was licensed under. I got back a "There is no license, I don't believe in software licensing." reply.
So, if you're out of technical arguments and are down to social ones, considering BIND is the Sendmail of the 90's and Weitse hasn't attacked DNS as a project I think you're out of wind.
Look at the code, don't rush to judgement. Look at BIND's code. Compare and contrast.
I actually *like* BIND, but running it is always scary, even chrooted.
Paul
1. PGP has never relied on obscurity.
2. "When it comes to things like my medical records, or bank statements, then I think I'd like them kept obscure"
I'd rather have mine kept secure. You seem to be mixing the two. Obscuring your records by XORing them and posting them to USENET probably won't give you the desired result.
3. NSA also doesn't give KG-84's, KY-71's or whatever they're using this year out to anyone who wants one, that gives them a decisive edge in this case (though I've always wondered why the physical boxes themselves were always security-rated lower than the information flowing through them.)
This story has a lot to do with security through obscurity, since "normal" bugs don't get this treatment, just security bugs.
Maybe you should re-evaluate the meaning of the term "security through obscurity", as you seem to be missing it.
Paul
There's _already_ a project that's most of the way to B-level functionality. It's at http://www.rsbac.de/ and it already works.
I think we should question the use of our tax dollars to reinvent this wheel when there's an active *FREE* implementation already most of the way done that doesn't use patented technology.
Paul
Microsoft handed these out at a conference one of my cow-orkers went to. He charitably donated them to science- erm, that is *my* specific experiment-
Take one MS action figure:
Duct tape to the end of a Nerf[tm] arrow.
Place wadding in other end of Nerf[tm] arrow.
Place C5-6 rocket engine after wadding.
Launch action figure above paved surface.
Unfortunately, they're not as destructable as Kenny was (Dammit! Me Bastard! I killed Kenny!)
They're not as aerodynamic either, Kenny got a good 1000', the MS guy couldn't go over about 600.
Next time the MS dude is gonna ride near the engine, in fact I'm considering rubber-banding them all around the fins with their heads in the blast area. Just gotta find some nose weight.
(See what you can learn at USENIX security?)
Paul
The problem is that there isn't a great pull for manufacturers to write to UDI. Most of them likely see "unsupported" OS' as a drain on their support resources, and that's a problem that needs to be fixed. It'd be nice to see RH or VA take some of that IPO money and start working on the problem. A driver support division somewhere with funding that could gain some mindshare would be cool, especially if it were non-proprietary.
FWIW, AIX ran on System/370 systems well over a decade ago, it never sold well. Try a search for AIX/370.
Paul
Lots of people use Sendmail. It's the default MTA for most *nixes. Personally, I prefer postfix:
www.postfix.org
It's mostly sendmail compatible, faster than most other MTAs, easy to configure, designed to be secure, and doesn't have the interaction problems that qmail sometimes does with other software. Sendmail is still the most flexible MTA on the planet, and for some people running legacy system gateways, there isn't a good alternative.
It's also easy for vendors to add sendmail (or postfix) to their OS distributions, qmail's license isn't favorable to 3rd parties.
Sendmail is the best "lowest common denominator" MTA. Postfix's sendmail compatibility program attempts to provide the base functionality necessary for _most_ external programs to work. Qmail doesn't even pretend to try to be sendmail compatible. Some people think that's an advantage, others don't. Because sendmail is monolithic, it can do things easily that modular mailers like qmail and postfix can't.
Paul
IBM's never been shy about releasing documentation and architecture reference manuals from the early 360 days through the 390 days.
On the other front, moving from running under VM to running without VM isn't _that_ difficult since IBM's VM looks a heck of a lot like the real hardware (surprise!) You'd probably need to port the SVC tables or perhaps provide most of the ones that fall under "OS Simulation Services" for VM (the ones like SVC 93/94 that the TPUT macros use.)
As far as running under VM (which a native version would be able to do as well)- the thing to get excited about is being able to host Linux applications without changing environments, and indeed writing collaberative applications to talk to other VMs. That gives you a signifcant software base for the S/390 that doesn't need to be supported seperately. So, you could run a mail system, USENET, or even hand out shell prompts and not take anything more than some CPU and I/O.
It also may give IBM some extra hardware for porting projects that can run batch compiles and things pretty quickly. If the port is done well enough, it may give IBM a good internal development platform. Now all they need is a good cross-compiler for i386.
Paul
There was an AIX/370 at one point. AIR it ran under VM. 370 was the architecture that preceeded the 390 architecture.
Thanks for playing.
Paul
There was an AIX/370 at one point. AIR it ran under VM. 370 was the architecture that preceeded the 390 architecture. OS390 is
Thanks for playing.
Paul
You're wrong about "go fast." A 747 at max throttle can outpace the stealth aircraft. Going fast generates too much of a heat signature and makes them less stealthy.
Paul
As has been pointed out, the GPL is a license, and
as a minor you can't agree to a license because that's entering into a contract. Minors can't do that in most countries. Corel isn't saying minors can't use Linux, they're saying they can't download it. If you invalidate this, you invalidate the GPL as a contract. Either the law needs to change on contracts, EULA's need to be struck down as invalid (whoops, there goes the GPL!), or you need to have mommy or daddy download the software for you.
As has also been pointed out, you can just go ahead and download the software yourself if you're a minor. You'll have an "illegal" copy and the GPL will still be enforcable and apply to your copy. Seems to me that this is the best solution given the current set of laws.
Corel and their legal department aren't at fault here. Instead of a sensationalist post about Corel, this should really have been about the state of the judiciary. Corel's lawyers have done the best they could given the parameters they have to operate in.
A more troubling question is if the minors who've contributed code can even license it at all without their parent's consent.
Paul
Ultra 2's are very fat pizza boxes and U5s are kinda fat pizza boxes. I've yet to see a mini tower Ultra outside of the Enterprise stuff that's tardis-like.
The newest Netra series are 1U high rack-mount pizza boxes - they look to rock too, especially for colo space where size is money. They're a cool charcoal color too.
SGI had a lot of early high-end Web business with the Challenge S, but Sun came in and spanked them, especially on the software side.
Probably the main failing of the Visual Workstation line is that it was too early. The lifetime on older workstations is a lot higher than on PCs, and I don't think SGI had the line funded to go out on much shorter than a PC cycle.
Paul
What do you think of the possibility of fall-out
lawsuits from harmed companies, and class-actions
on behalf of consumers will be (a) if the DOJ case
goes to decision, and (b) if it's settled?
Is there any compelling reason for Microsoft to
worry about similar suits in other countries? Has
there traditionally been a follow-on of suits in
non-US courts when a company such as IBM was found
to be abusing a monopoly status?
What are the chances for the DOJ to settle
given the fact that litigating the case fully
will set precident? Do you agree or disagree
with the premise that it should be litigated
rather than settled to provide precident?
Thanks,
Paul
For anyone who can't get it to Babel, basicly they're contributing funding to improve the interface, develop for multiple OSen and add capability to mail clients to use it. Also, it seems this is an initial investment, not just a one-time thing.
This is amazingly cool. A government that is going to support Open Source security tools as an end in itself due to transparency of the source, reliability and I'd assume economic benifits as well.
Paul
IANAL - take with a grain of salt.
I'd expect that as a student, you'd get some sort of "fair use" protection, just as I'd expect an underground "student publication" to. You'll want to read up on trademark/fair use stuff, or try to find a lawyer who'll give you an idea of the applicablility of fair use. The fact that they're not even questioning the content of the site would make me wonder seriously about it. If a student can't use their University's name, then what value is that affiliation? I'd also go to the local campus newspaper and start trying to get them interested in a story. If you can find a friendly lawyer who thinks you've got a fair use exemption, then have them send an answering letter to the University. You may also want to make sure it's perfectly clear on the main page that the site isn't affiliated with the University and that they own the trademark. It's easier to win if you can prove that there's no dilution of their mark. Their case will probably be about dilution, focus on that, not on just using the name. Also, use disclaimers in any mail you send from the domain.
Talk to a lawyer if at all possible, and try the "Dear University, I feel my site is covered by fair use doctrine, however I've added strong language to the disclaimer on my site to protect you from dissolution of your mark. If you'd like the text of the language changed, I'd be happy to work with you to come up with mutually agreeable verbage." Watch how it's worded though, you don't want to admit an infringement, just that you want to reach an agreement without giving up your domain.
HTH,
Paul
I wonder if this is the end of the US-based domination of the World's software? Korea seems to have decided that Microsoft is strategicly bad to deal with and that Linux is a better choice. I'm pretty sure I've read that Mexico's school system is going to Linux.
The big question is "Unless the Linux-on-the-desktop crowd are significantly successful soon, will it mean that the clue-per-person index will go up in 'developing countries' while it's declining in 'developed countries?'"
The US Government's policies and strategies seem to be tilted towards commercial entities, not the efforts of the population at large (e.g. crypto binaries ok, crypto source bad) - countries with less disposable income in their populations are taking national strategic advantage of free (as in beer), and that could have serious long-term impact on the global computing environment.
More clue is good. I'm just worried that a lot of US and European policy-makers are buying into the less-skilled workplace being good and long term it seems to be a less-than-ideal solution.
Paul
With IPSec starting to gain some momentum as well as the current VPN craze (which seems to ignore the traditional encryption boundary issue completely), do you see a role in the testing and certification of vendor implementations to include checksumming of binary-only closed-source products and services?
Given that we'll soon see more Voice over IP, and we're currently seeing IPSec in routers, is there any other way the international community can be sure that a particular implementation hasn't been (legally or illegally) trojaned by a manufacturer or that they can gain a high level of trust in their vendors' implementation?
So long, and thanks for all the fish!
Paul
Basicly the USG is arguing in Bernstein's case that because there's an off chance they'll modify the export regulations, the case should be delayed. He's pointed out that they've said this before (when the export regs. moved to commerce), and it didn't happen.
What really needs to happen is that the full court needs to uphold the decision that software source code is covered by 1st ammendment protection. Then no matter what, it can't be legislated against. That's much more important than the government simply changing its export stance temporarily.
Paul
Linux/Unix isn't "virus proof" by design. Viruses are more difficult to spread, but it's possible- *especially* these days with less-sophisticated administrators and more frequently updated software. It's fortunate that we don't have anything more than a handful of concept viruses.
Trojan horses are more worrying than viruses though. It is possible to secure Linux from both threats, but that makes administration more difficult, and may mean not using stock kernels.
Paul
OS400 only runs on AS/400s, which are a different market than PC or Server-class machines. There's not a direct conflict, but it could be construed as one if AS/400 sales fall due to over-advocacy in another division.
Exactly what "Linux security measures" are you concerned about? How far are you willing to go to secure a Linux system yourself? If you're interested in significant security, check out http://www.rsbac.de/ Most Linux systems that are insecure are that way because nobody's taken the time to secure them. Good or bad, it's a mostly solvable problem. RSBAC places even more security oppertunities on the table.
Paul
I worked for somewhere that had GRiD Compasses and GRiD Cases in a past life. We had quite a few of them, and they all ran DOS. If you drop it on a corner, you'll break the plasma screen (we broke a few like that, but give our "normal" treatment they were amazingly rugged.)
;)
:)
The was a TEMPEST rated version, and in fact I had one of each that I kept in the trunk of my car. I actually came across a power brick for one of these last time I moved. My "rationale" for one of each was that I had to be able to "test programs on the TEMPEST version as well." I guess management's clue level over the years hasn't changed much
The TEMPEST ones also had a pretty cool encryption option. Bubble memory helped with not having to rely on magnetic media as well. The only problem with the Crypto option was that you weren't allowed to leave them in the trunk of your car
GRiD used to run over them with jeeps and drop them from helicopters in sales demos back then. Nothing else would stand up to it.
I think I seriously hurt the TEMPEST version of a Compaq Luggable that I had in for testing once. The GRiD's would take a heck of a lot more abuse.
New GRiDs were somwhere between $17,000 and $27,000 if I recall correctly. CryptoGRiDs might have been more.
GRiDCase's had better and bigger screens than the Compass, but weren't TEMPESTable AIR.
Paul
Point (A) said "spoofing in general" for the reason that there was a lot of more 'academic' discussion going on than discussion limited to the particular case in point...
... but are
.au doesn't have a great ammount of off-continent bandwidth (though it's certainly better than it used to be) so you'd probably be looking for on on-continent routing hole at either end if you were preparing an attack. (limted bandwidth tends to be managed better than widely available bandwidth)
> Very wrong. If you've followed bugtraq the last > week or so, you would've noticed the "bug" in
> the linux 2.2 kernel that makes blindspoofing
> easy on a network with little lag. On the...
Once again, as the attacker you get to pick what's spoofed. Spoofing from a blackholed network or from an easily-flooded host removes the lag issue completely. Synched clocks only work for similar implementations that derrive their sequence numbers from the time.
> Any recent tcpip implementation should should
> have difficult to predict sequence numbers. I
> don't know how older systems works, so you're
> probably right.
"Should" and "do" are two different things. Making difficult sequence numbers affects TCP performance. At least for relatively recent versions of HP/UX you have to sysctl hard numbers, and the default was easily guessable. If you've a
decent collection of hardware you can run nmap or ISS and look at the predictability of your hosts.
> I have a tendency to believe that most
> core-routers are well-configured. Of
> course, there are extreme amounts of poorly
> administered routers
> there extreme amounts of poorly administred
> core-routers?
(a) a leaf router will do quite well in this instance and (b) it only takes one, extreme ammounts don't mean much. Some tier-1's manage their routers well, and some manage them poorly.
Paul
I think it's an injustice to lump information warfare in with "traditional" NBC-type warefare.
The problems of INFOSEC today are the infrastructure of tomorrow. Power grids, water treatment plants, telecommunications infrastructure, etc. are all quite vulnerable in at least several instances. Don't forget that it doesn't take an anonymous long-distance attack to get "in." A virus on a demo CD, a trojan in an executable "greeting card", etc. Timebombed code can be left by a temporary employee, cleaning person with physical access...
Today, employers, even those who are running critical infrastructure are hard-pressed to not give employees Web access (401k plans, health insurance plans and others are starting to _mandate_ it) Most of those employees are on inseucre, poorly administered, untrusted desktop operating systems. Add SSL and VPNs to make tunneling next-to-impossible to detect and you've got a recepie for serious electronic mayhem.
The barrier to entry here isn't very high. If you look at the number of viruses and compromised hosts on the Internet, and see if you can get hold of the statistics for telephone fraud that relate to compromised PBX's. You'll see that the knowlege is already fairly easy to gain. It's fairly easily transferable too. But *there's no need to transfer it*. Recruiting people who are already good at it should be trivial for most either well-funded organizations or organizations with a strong "appeal" to either a targeted individual, or a member of the target's preferred sex group. Ideologies tend to be better draws, but it wouldn't be difficult in either case, nor would extraction of several unwilling potential accomplices. One sympathetic organization member with competence would probably have a trivial time recruiting as well.
Some of the people who have the skillsets aren't socially very far evolved, don't necessarily have access to material things they'd like and are under age. All of those groups are easily targeted.
It's all software and easily gained knowlege, and testing is trivial and not necessarily dangerous. Unlike most traditional weapons, it's fairly simple to test out information attacks without anyone detecting it because you can do it on your own systems.
Until infrastructure vendors start making secure-by-default infrastructure (switches and hubs predominantly) and it becomes widespread in the install base, things like hospitals, power plants, water and waste treatment facilities, telephone exchanges, banks, etc. will be good targets of oppertunity.
While some places practice good security, not all do. It's becomming quite trivial to place a small 2" square machine onto a LAN port. Wireless networking on the back side and you're in. For less than USD$1000 you could build such systems and disguise them as appliances like lamps.
Not many places outside of the national security arena even do RF sweeps. Infrared is starting to make even that less useful.
Look at what the failed S&L industry cost, it's possible to disrupt commerce in key segments enough to cause millions of dollars of damage today, and billions over the next 5-10 years, not all electronic terrorism need be traditonal warfare, economic warfare is just as valid.
We're "used" to terrorists who directly cause terror, now we're building the capability for them to set events in motion that have longer-term effects and aren't first-order effects.
Finally, the combination of electronic and unconventional warfare, since they need not be exclusive, is a new one. False SNMP trap, compromised phone switch and a ready to deploy "customer engineer" is just one example that springs immediately to mind.
I could go on and on, but that's probably enough for now.
Paul
> and since that is next-to-impossible to
> accomplish on the net (due to lag, and pretty
> random numbers used in the handshakes) -- we can
> pretty much rule that out.
(A) You're missing the fact that TCP isn't the only protocol you can blindly spoof. So, if we're talking about spoofing in general, there's a UDP and ICMP-sized hole there waiting for poorly written applications.
(B) Lag has _nothing_ to do with a blind spoof attack, since you can either flood the spoofee or pick a host that's behind a network that doesn't report unreachables.
(C) Very diffuclt to predict sequence numbers are a relatively new occurance. I wouldn't bet my hard-earned money on everything using them either.
(D) Why are you ok with cracked end-boxes, but not
anything cracked in the path? You wouldn't believe the number of poorly administered routers, older routers with vulnerabilities, and new Web browser configuarble routers set up by morons.
Your conclusion is probably correct, but your premises are flawed.
Paul
> You've got to get packets back to yourself, to
> get to know what ports are open. In other words
> -- it's not that easy. You've got to be "in
> between" so that you can packetsniff the packets
> coming from the host you're scanning, and the
> address you've spoofed.
>
> (correct me if i'm wrong)
What's often overlooked is that 'in between' can be *either* in between the scanner and the victim or the victim and the spoofee. If you do the second part, it's more likely that you'll have a case of denyability if you're also the spoofee if you can route the replies to the spoofed packets out-of-band.
"We were sniffing our network that day because we seemed to be under some sort of attack, here're the logs and you can see that we didn't send any traffic out, it must have been spoofed" is possibly a good defense in such situations, especially if the spoofee is say a college network with a significant number of hosts and shared media.
Paul