l00s4h==luser==loser==acct with minimal privs used for running risky (i.e. networking) apps.
typically used with an "airlock":
- luser acct has rw access to a directory which is also readable by your normal user account. - files are downloaded by luser processes into this shared directory... - and immediately moved into a directory which is rw for your normal acct but inaccessible to luser.
If (when?) a luser process is compromised, it can only corrupt/distribute stuff still inside the airlock; the rest of your data is (ideally) safe.
I wish mozilla etc would put a GUI on this technique.
Agree 100%. It's kind of like how it _is_ the consumer's fault when the tires on a JumboSUV randomly explode. Even senior automotive executives know you should drive straight from the dealership to get aftermarket replacements! And if the tires blow on the way to get replacements, well, you should have had the wheels xrayed prior to leaving the lot.
Dude... can you believe some people don't even bring a portable xray machine when buying a new car?
I love Linux and have used it since 1996, but I don't love half-truths. Mods, do what you must:
1. Unless you have a special 'l00s4h' account for running network programs, you can lose anything owned by your normal account. Typically that's all your data (norp, zeraw, 3PMs, financial data, etc). You're saying losing all that stuff is _better_ than losing the core OS, which you can replace over HTTP in 10 minutes?
2. Even with 'l00s4h', if your kernel has priviledge escalation bugs, bad guys can still get r00t. Linux had two of these in the past six months.
3. You've personally audited mutt for overflow issues? How about the 1GB mozilla codebase?
4. You trust Debian? Gentoo? GNU? Even though they don't always cryptographically sign binaries and even though their servers were 0wned a few weeks back?
5. apt-get, emerge, etc don't typically use SSL, so how do you know you aren't being man-in-the-middled when you run it (as root)?
Linux can be made more secure than d0ze--but don't delude yourself, or others.
I love Linux so I want to agree, but consider this:
1. You can't really turn off Linux mremap() 2. sshd is critical on remote Linux machines. You can't just turn it off if it's vulnerable. 3. Repeat #2 for Apache, BIND, sendmail, etc.
4. The RPC TCP ports etc are _not_ required on a large portion of Windows desktop machines. 5. Microsoft is (finally) putting a firewall in XP SP2 that could (potentially) mask much of this attack surface.
I do agree that open source is more flexible in terms of security. However not all of the flexibility translates into practical advantage. I think it's more feasible to close TCP ports on your average Windows client machine than on a Linux server.
The really big win with open source is that you could, if your data is worth it, hire someone to audit the code prior to rolling it out. With Windows you are playing russian roulette with a mostly loaded gun.
One technical point: you cannot just "disable" mremap() without breaking the dynamic link loader and many userspace applications. There was, however, an unofficial kernel module that you could load into a vulnerable kernel to replace sys_mremap with a non-exploitable version (which in theory is racey, but it basically works and postpones the reboot).
That's a very naive, idealistic argument. American business often maximizes shareholder value by being as dishonest as possible, short of clearly breaking commonly enforced laws. Under your argument, Darl McBride is a "good guy" because he's a) rich from the SCOX pump-n-dump and b) not in jail (yet).
Anyway, go read "The Art Of War" or watch "The Godfather". It is a serious error to assume your enemy is weak, and I would recommend against that philosophy when securing critical assets.
char buf[10]; strcpy(buf, "Network Data From Script Kiddie"); return;
At the $2/hour rate my offshore replacement earns, that code costs about one tenth of one American cent. Pay an artist to put some eye candy on it, and you, sir, have Microsoft Windows. How, exactly, did we just spend $100,000,000.00?
Note For Windows Zealot Mods: I'm kidding. Note For Linux Zealot Mods: I'm not kidding.
With huge, cheap disks these days, source-based distros could optionally start keeping the entire source+object tree around. Upgrading is then a matter of patching and rebuilding only the changed objects, and that is often considerably faster than a full build. For developers, there are major debugging advantages as well.
May not help with major upgrades, but it's great for small security patches etc. Compare the build+relink time for mremap.o vs a full kernel...
A company I work for has a few hundred developers using Perforce. At home I've been using svn for a few months. Here's my quick comparison:
Perforce: Pros: - Very fast. Very, Very, Very fast. - Stable - Decent cross platform support Cons: - Commercial (but not as expensive as BK) - Binary-only--we can't (easily) fix it. - Windows UI is a bit inconsistent - Requires manual checkout - Requires server for revert, diff, etc - Stores client state on server. Thus there are coherency issues--if you 'rm' a subtree on the client, the server still thinks the client has it, and 'p4 sync' will not refretch it. It took developers a while to grasp the need for 'p4 sync -f' in this situation.
Subversion: Pros: - OSS License - More features than CVS (already covered) - Automatic file open (you can just start editing a file in a checked out module) - 'svn status' - Serverless revert, diff. - Short learning curve - Active developer/user community Cons: - Berkeley DB. Data does not seem to be very portable between different library versions. Yes, you can dump and reload, but the lack of binary compatibility is lame. - SVN Schema Changes. These also require manually dumping and reloading the repository. SVN developers claim schema changes will be rare as of 1.0. I've been through three so far... we'll see. - Berkeley DB. 50k in text takes 2-3MB in the DB. "Fortunately" there are arcane manual tools to prune it. - Performance. Not slow, but local svn is slower than LAN Perforce. - Berkeley DB. Twice I had to run db_recover when svn 0.36.0 locked up and/or refused to run. Tangential evidence suggests DB 4.2 fixed the bugs. Make frequent gzip'd backups of 'svnadmin dump' and you should be OK. Also test rigorously before you deploy--this is a 1.0, after all.
So basically "think different" means "you admire how we think so let us think for you"?
Heh. In the Microsoft world, the vendor pushes a monoculture. In the Apple world, the customers pull a monoculture. In Linux there is no monoculture--and that is why it will take over the world.
Ahh! You must be the fabeled non-evil twin. The next time you see Darl, please tell him his website appears to be down. We didn't do it, but to be totally honest, SCO is making us a wee bit miffed.
Thankfully many onboard audio systems do have an SPDIF optical/coaxial out that you can connect to a dedicated DAC.
Or you can just use USB; the EMagic 2|6 and Edirol UA-5 work well under ALSA and are prosumer studio quality for $200-$300. If you're into softsynth the USB stuff also tends to have low latency, and still works nicely on a laptop.
Hardware NX was probably covered briefly because commodity x86 parts do not support it--it will not work for p4, athlon xp, etc.
It'd be interesting to compare the MS software techniques to what's availible on Linux (Ingo Molnar, Solar Designer's noexec stack work etc). Of course I doubt Microsoft will release anything other than a marketoid explanation.
Microsoft has no business nor technical reason to release core code. As long as they have massive market share, hardware manufacturers will cope with *any* driver development obstacles.
In fact keeping development hard creates a lot of high-paying jobs for Microsoft allies.
BTW, it's not cheap to maintain a Linux driver either. But if you release specs, other people will probably write and maintain a GPL'd one for you (ATI Radeon 8500 etc)
Great. Now some PHB is gonna spec embedded Windows 98 inside life support equipment. And claim that it's a good idea because the hospital already has a Microsoft site license...
Intriguing... Maybe speculators have been buying SCOX in expectation of a profitable settlement after the stock bombs and there is a class action mismanagement and/or securities fraud suit?
Slashdot Mirror
Dude, this is slashdot... You have to be more specific.
What's a girl?
It is an even sadder day for /. when a post calling it ./ is modded +4.
Anywhere else, and I could believe your wit is actually that subtle.
Here on dotslash, it was probably just lack of proofreadi
l00s4h==luser==loser==acct with minimal privs used for running risky (i.e. networking) apps.
typically used with an "airlock":
- luser acct has rw access to a directory which is also readable by your normal user account.
- files are downloaded by luser processes into this shared directory...
- and immediately moved into a directory which is rw for your normal acct but inaccessible to luser.
If (when?) a luser process is compromised, it can only corrupt/distribute stuff still inside the airlock; the rest of your data is (ideally) safe.
I wish mozilla etc would put a GUI on this technique.
Agree 100%. It's kind of like how it _is_ the consumer's fault when the tires on a JumboSUV randomly explode. Even senior automotive executives know you should drive straight from the dealership to get aftermarket replacements! And if the tires blow on the way to get replacements, well, you should have had the wheels xrayed prior to leaving the lot.
Dude... can you believe some people don't even bring a portable xray machine when buying a new car?
I love Linux and have used it since 1996, but I don't love half-truths. Mods, do what you must:
1. Unless you have a special 'l00s4h' account for running network programs, you can lose anything owned by your normal account. Typically that's all your data (norp, zeraw, 3PMs, financial data, etc). You're saying losing all that stuff is _better_ than losing the core OS, which you can replace over HTTP in 10 minutes?
2. Even with 'l00s4h', if your kernel has priviledge escalation bugs, bad guys can still get r00t. Linux had two of these in the past six months.
3. You've personally audited mutt for overflow issues? How about the 1GB mozilla codebase?
4. You trust Debian? Gentoo? GNU? Even though they don't always cryptographically sign binaries and even though their servers were 0wned a few weeks back?
5. apt-get, emerge, etc don't typically use SSL, so how do you know you aren't being man-in-the-middled when you run it (as root)?
Linux can be made more secure than d0ze--but don't delude yourself, or others.
One thing they have in common:
Both are now open source.
Almost. It's OK to steal Windows if you're researching remote exploits. However, we do NOT advocate stealing BSD, because BSD is dying.
Sincerely,
The Slashdot Troll Hive Mind
I love Linux so I want to agree, but consider this:
1. You can't really turn off Linux mremap()
2. sshd is critical on remote Linux machines. You can't just turn it off if it's vulnerable.
3. Repeat #2 for Apache, BIND, sendmail, etc.
4. The RPC TCP ports etc are _not_ required on a large portion of Windows desktop machines.
5. Microsoft is (finally) putting a firewall in XP SP2 that could (potentially) mask much of this attack surface.
I do agree that open source is more flexible in terms of security. However not all of the flexibility translates into practical advantage. I think it's more feasible to close TCP ports on your average Windows client machine than on a Linux server.
The really big win with open source is that you could, if your data is worth it, hire someone to audit the code prior to rolling it out. With Windows you are playing russian roulette with a mostly loaded gun.
One technical point: you cannot just "disable" mremap() without breaking the dynamic link loader and many userspace applications. There was, however, an unofficial kernel module that you could load into a vulnerable kernel to replace sys_mremap with a non-exploitable version (which in theory is racey, but it basically works and postpones the reboot).
That's a very naive, idealistic argument. American business often maximizes shareholder value by being as dishonest as possible, short of clearly breaking commonly enforced laws. Under your argument, Darl McBride is a "good guy" because he's a) rich from the SCOX pump-n-dump and b) not in jail (yet).
Anyway, go read "The Art Of War" or watch "The Godfather". It is a serious error to assume your enemy is weak, and I would recommend against that philosophy when securing critical assets.
char buf[10];
strcpy(buf, "Network Data From Script Kiddie");
return;
At the $2/hour rate my offshore replacement earns, that code costs about one tenth of one American cent. Pay an artist to put some eye candy on it, and you, sir, have Microsoft Windows. How, exactly, did we just spend $100,000,000.00?
Note For Windows Zealot Mods: I'm kidding.
Note For Linux Zealot Mods: I'm not kidding.
You can. Just make sure you grab a Visual C++ torrent at the same time.
I think there's a Visual C++ source release coming out soon too, but you'll probably still need a binary version to bootstrap it.
With huge, cheap disks these days, source-based distros could optionally start keeping the entire source+object tree around. Upgrading is then a matter of patching and rebuilding only the changed objects, and that is often considerably faster than a full build. For developers, there are major debugging advantages as well.
May not help with major upgrades, but it's great for small security patches etc. Compare the build+relink time for mremap.o vs a full kernel...
In the Microsoft wet dream, customers are also paying them monthly for the priviledge of these secret automatic updates.
Though, they are finally adding a firewall in XP SP2. Maybe the recent Linux deployments are putting on some heat?
A company I work for has a few hundred developers using Perforce. At home I've been using svn for a few months. Here's my quick comparison:
Perforce:
Pros:
- Very fast. Very, Very, Very fast.
- Stable
- Decent cross platform support
Cons:
- Commercial (but not as expensive as BK)
- Binary-only--we can't (easily) fix it.
- Windows UI is a bit inconsistent
- Requires manual checkout
- Requires server for revert, diff, etc
- Stores client state on server. Thus there are coherency issues--if you 'rm' a subtree on the client, the server still thinks the client has it, and 'p4 sync' will not refretch it. It took developers a while to grasp the need for 'p4 sync -f' in this situation.
Subversion:
Pros:
- OSS License
- More features than CVS (already covered)
- Automatic file open (you can just start editing a file in a checked out module)
- 'svn status'
- Serverless revert, diff.
- Short learning curve
- Active developer/user community
Cons:
- Berkeley DB. Data does not seem to be very portable between different library versions. Yes, you can dump and reload, but the lack of binary compatibility is lame.
- SVN Schema Changes. These also require manually dumping and reloading the repository. SVN developers claim schema changes will be rare as of 1.0. I've been through three so far... we'll see.
- Berkeley DB. 50k in text takes 2-3MB in the DB. "Fortunately" there are arcane manual tools to prune it.
- Performance. Not slow, but local svn is slower than LAN Perforce.
- Berkeley DB. Twice I had to run db_recover when svn 0.36.0 locked up and/or refused to run. Tangential evidence suggests DB 4.2 fixed the bugs. Make frequent gzip'd backups of 'svnadmin dump' and you should be OK. Also test rigorously before you deploy--this is a 1.0, after all.
So basically "think different" means "you admire how we think so let us think for you"?
Heh. In the Microsoft world, the vendor pushes a monoculture. In the Apple world, the customers pull a monoculture. In Linux there is no monoculture--and that is why it will take over the world.
Ahh! You must be the fabeled non-evil twin. The next time you see Darl, please tell him his website appears to be down. We didn't do it, but to be totally honest, SCO is making us a wee bit miffed.
Sincerely,
The Linux Community
Thankfully many onboard audio systems do have an SPDIF optical/coaxial out that you can connect to a dedicated DAC.
Or you can just use USB; the EMagic 2|6 and Edirol UA-5 work well under ALSA and are prosumer studio quality for $200-$300. If you're into softsynth the USB stuff also tends to have low latency, and still works nicely on a laptop.
Hardware NX was probably covered briefly because commodity x86 parts do not support it--it will not work for p4, athlon xp, etc.
It'd be interesting to compare the MS software techniques to what's availible on Linux (Ingo Molnar, Solar Designer's noexec stack work etc).
Of course I doubt Microsoft will release anything other than a marketoid explanation.
Yeah, I heard DJ's server power-offed itself to avoid 2.6.0 and the inevitable slashdotting...
127.0.0.1
The brk and ptrace issues require local user access and are not remotely exploitable.
Microsoft has no business nor technical reason to release core code. As long as they have massive market share, hardware manufacturers will cope with *any* driver development obstacles.
In fact keeping development hard creates a lot of high-paying jobs for Microsoft allies.
BTW, it's not cheap to maintain a Linux driver either. But if you release specs, other people will probably write and maintain a GPL'd one for you (ATI Radeon 8500 etc)
Great. Now some PHB is gonna spec embedded Windows 98 inside life support equipment. And claim that it's a good idea because the hospital already has a Microsoft site license...
/* much faster to shit than get off pot */
Intriguing... Maybe speculators have been buying SCOX in expectation of a profitable settlement after the stock bombs and there is a class action mismanagement and/or securities fraud suit?