Request: Easy way to "elevate" programs


Lots of ways. The argument starts with the assumption that the probability that there is someone willing to take the time to find and exploit a bug in the code for nefarious purposes is not zero. If you assume that there is literally no chance that anyone could want to compromise your Pandora then yes, automatic is strictly better than by hand, but if there's no fear of compromise then you may as well just stick a "yourusername ALL = NOPASSWD : ALL" into the sudoers file and be done with it.

But if there is even a sliver of a chance that someone might find a buffer overflow and inject their own code into it then security tilts entirely in favour of manual updates.
 
Maybe I don't have a complete understanding of the security concept at hand: Why is it different from other applications/programs/jobs/etc. that are already in place that run outside of the users security context ?
 
Last edited by a moderator:
They don't live in regular user writable locations, they get updates pretty much only from a single verifiable source (with firmware updates) and they are in general a controlled subset of programs that don't deal with any funky stuff :)
 
They don't live in regular user writable locations, they get updates pretty much only from a single verifiable source (with firmware updates) and they are in general a controlled subset of programs that don't deal with any funky stuff :)
Why couldn't the application I "request" be a part of that group ?
 
Last edited by a moderator:
It can, on a case by case basis with things like sudo and its GUI brethren.

They're not usually granted permanently elevated rights because any other program running as the same user can change their configuration and run them with the elevated rights. Say it's a PND. It's quite trivial to modify the elevated PND's run script to do nasty stuff as another program with regular rights, then run the elevated PND and get that nasty stuff run as a super user. It's basically giving any program superuser rights. Because of how PND appdata works you can't really just make the PND non-writable either because anything inside it can be overridden with appdata, which is again writable by the user.
 
Why couldn't the application I "request" be a part of that group ?
It can and by giving something elevated privileges you're technically compromising security as well but you are still making the choice to compromise the security for something you deem useful.It's like giving your house key to a friend: you probably trust them, but there's a chance that they may lose that key, or get pissed off at you for some reason and just walk in and thrash your house, and that would be bad. But the automated script to elevate other processes is like giving your friend a key cloning machine. If your friend loses that one key it's bad and someone could come in and steal or break something, but if they lose the key cloning machine it's really bad and multiple people could come in and steal different stuff, break different stuff, everyone who gets a cloned key might use it for different purposes. Other parts of the analogy: a single key is small and hard for someone to find and steal from your friend, whereas a key cloning machine is bigger and more obvious to see and therefore likely to be a bigger target for theft and bad usage.

Statistically speaking you are almost certainly safe to do what you want to do, but it's not zero, it is strictly safer to manually give permission to what you trust. It's still not safe, just safer. The difference in safety may not be enough to balance out the benefits of not having to type in your password all the time so ultimately do what you think is best.
 
First, sorry for not beeing able to see the obvious, but I can't help myself getting the "wall" out of my way

It can, on a case by case basis with things like sudo and its GUI brethren.

They're not usually granted permanently elevated rights because any other program running as the same user can change their configuration and run them with the elevated rights. Say it's a PND. It's quite trivial to modify the elevated PND's run script to do nasty stuff as another program with regular rights, then run the elevated PND and get that nasty stuff run as a super user. It's basically giving any program superuser rights. Because of how PND appdata works you can't really just make the PND non-writable either because anything inside it can be overridden with appdata, which is again writable by the user.
But isn't that more an intrinsic problem of granting software elevated rights in a user context ? I don't see any difference, wether I have to enter the password everytime I start the program or only once > If I don't notice that it (now) contains malicious code, I have a problem either way.

Why couldn't the application I "request" be a part of that group ?
It can and by giving something elevated privileges you're technically compromising security as well but you are still making the choice to compromise the security for something you deem useful.
It's like giving your house key to a friend: you probably trust them, but there's a chance that they may lose that key, or get pissed off at you for some reason and just walk in and thrash your house, and that would be bad. But the automated script to elevate other processes is like giving your friend a key cloning machine. If your friend loses that one key it's bad and someone could come in and steal or break something, but if they lose the key cloning machine it's really bad and multiple people could come in and steal different stuff, break different stuff, everyone who gets a cloned key might use it for different purposes. Other parts of the analogy: a single key is small and hard for someone to find and steal from your friend, whereas a key cloning machine is bigger and more obvious to see and therefore likely to be a bigger target for theft and bad usage.
Statistically speaking you are almost certainly safe to do what you want to do, but it's not zero, it is strictly safer to manually give permission to what you trust. It's still not safe, just safer. The difference in safety may not be enough to balance out the benefits of not having to type in your password all the time so ultimately do what you think is best.
(As often) I'm having some trouble with your analogy: As I am currently thinking how my idea "works", ist not just giving a friend a key to my house. Its more like a "lawgiver" key that is encoded to the DNA of my friend, but instead of blowing of my friends hands when he tries to let the key out of his hands, it automatically calls me and asks for my consent.
 
But isn't that more an intrinsic problem of granting software elevated rights in a user context ? I don't see any difference, wether I have to enter the password everytime I start the program or only once > If I don't notice that it (now) contains malicious code, I have a problem either way.
Suppose it's not you starting the elevated program, but another PND with a malicious update. With no password needed to run the program with elevated rights combined with the possibility to write to its data means the malicious PND can run your elevated PND to do its bidding. If running the PND with elevated rights requires a password, on the other hand, the malicious PND would need it as well.

With the password you only need to trust the one PND you're running elevated. Without it you need to trust every single program you run.
 
Last edited by a moderator:
As I am currently thinking how my idea "works", ist not just giving a friend a key to my house. Its more like a "lawgiver" key that is encoded to the DNA of my friend, but instead of blowing of my friends hands when he tries to let the key out of his hands, it automatically calls me and asks for my consent.
This is starting to remind me of Lexx.
 
But isn't that more an intrinsic problem of granting software elevated rights in a user context ? I don't see any difference, wether I have to enter the password everytime I start the program or only once > If I don't notice that it (now) contains malicious code, I have a problem either way.
Suppose it's not you starting the elevated program, but another PND with a malicious update. With no password needed to run the program with elevated rights combined with the possibility to write to its data means the malicious PND can run your elevated PND to do its bidding. If running the PND with elevated rights requires a password, on the other hand, the malicious PND would need it as well.

With the password you only need to trust the one PND you're running elevated. Without it you need to trust every single program you run.
Ah, ok, thats a good point - thanks. It would not apply to my special usecase, but as my request would have a more broad impact, I guess its a bad idea after all.
 
The easiest way to exploit your idea would be another PND to drop a modified "script" with the same name in your AppData folder - When the PND is mounted, your PND version is replaced with the AppData version and bingo!
 
Ok, there seems to be two overlapping conversations going on here. I've specifically been addressing what you said here

So what you are basically saying is that a tried and tested solution to alter a file is more prone to error than someone editing the file manually?
trying to explain why allowing a program to update the sudoers file is less secure than manually updating the file yourself. I haven't been trying to talk about the merits and problems of even giving a PND elevated privileges in the first place (although some of that slipped in), just that if you're going to do it, one-by-one is safer than having some app which does it for you.It isn't safe but honestly the instant you turn on your computer you're no longer safe, but if you feel safe enough it's pretty easy to just add the PNDs run commands to the sudoers file.
 
Speaking of security, there is no way you can grant root permission to something residing on your SD and remain secure. One solution is to define a set of priveleged actions (like mounting, switching on WIFI, changing screen brightness, setting hardware alarm etc.) which don't require a password, create executables for these action on the NAND and add those to sudoers. The problems:

1. it's impossible to foresee all such actions

2. it is impossible to modify all the existing PNDs which just run gksudo in the beginning and do everything as root, even if all they need is one action

I once proposed an intemediate solution, which consist in authorizing a broad group of actions (like writing to /sys filesystem). Of course there is a risk that a knowledgeable hacker finds a way to misuse it for privilege escalation, but it's not as straightforward, and how many hackers would target openpandora, really? It is possible to go even further and authorize mount, insmod, opkg et cetera, but more stuff you allow, and less security you get. You could even go as far as adding cp and ln to the list, but it would be as secure as no password at all.

The problem #2 still remains though. If the PND you use starts with gksudo ./myscript.sh, there is nothing you can do to run it without password, apart from ruining security completely.

EDIT:

Security is only good if it protects against real threats, not imaginary ones. A malicious PND might as well use gksudo, and many users would enter the password without looking inside. If your pandora is physically lost, the NAND will be reflashed without any password at all, and personal data on your SD card will be as unprotected as if the attacker knew your root password.
 
Last edited by a moderator:
D'OH, I made a small script that starts the pnd I refer to in the sudoers file.
This might be a solution, provided that your script checks the PND's fingerprint and wipes any scripts from its appdata folder. Still, I guess it's possible for a malicious process to watch on the appdata folder and restore the scripts in it while the PND is mounting.
 
Last edited by a moderator:
Ok, there seems to be two overlapping conversations going on here. I've specifically been addressing what you said here

So what you are basically saying is that a tried and tested solution to alter a file is more prone to error than someone editing the file manually?
trying to explain why allowing a program to update the sudoers file is less secure than manually updating the file yourself. I haven't been trying to talk about the merits and problems of even giving a PND elevated privileges in the first place (although some of that slipped in), just that if you're going to do it, one-by-one is safer than having some app which does it for you.
It isn't safe but honestly the instant you turn on your computer you're no longer safe, but if you feel safe enough it's pretty easy to just add the PNDs run commands to the sudoers file.
Ok then, your last entry regarding that particular part was your analogy, which I already replied to.
 
As I am currently thinking how my idea "works", ist not just giving a friend a key to my house. Its more like a "lawgiver" key that is encoded to the DNA of my friend, but instead of blowing of my friends hands when he tries to let the key out of his hands, it automatically calls me and asks for my consent.
That's the difference: giving a friend a key is like manually updating the sudoers file so that one app has root access. Maybe that friend gets compromised, but it's just one key and you'll know where it came from because of what was exploited. If you grant explicit permission to ABC.PND and you become compromised you can discover that ABC.PND was updated or a file was dropped into its appdata directory and you'll be able to say "hey everyone, watch out, someone is hacking ABC.PND".Your idea is the "key cloning machine" that you give to a different friend you trust to only give keys to other friends: if that gets lost or compromised you risk EVERYONE getting a key, and then you'll have no idea the true source of the attack. Sure, someone compromised your key cloning machine, but if ABC.PND has some hidden code just waiting for it to get root and suddenly it is given a key you won't have any way of knowing that.

You are always safer manually handing out single keys than trusting someone to hand out keys on your behalf.

As far as "encoded to DNA", if that's the analogy you want to use then be aware that it is very very easy to "clone" someone. There's no way really to verify that the person (application) with the key is actually the same person (application) you originally gave the key to. You just have to trust that someone hasn't snuck into your friends house, killed your friend, and replaced him with an evil clone that can now use all his keys.

SD card storage makes it very easy to "kill and replace" your "friends" (PNDs). That was actually one of the benefits of the PND.

Two things you could do: format your SD card EXT2 and make sure the permissions on the PND and appdata are root writable only; or put the PNDs on the NAND (if you have the space for it) and again make their appdata directories root writable only. Much safer.
 
That's the difference: giving a friend a key is like manually updating the sudoers file so that one app has root access.

[...]
Your idea is the "key cloning machine" that you give to a different friend you trust to only give keys to other friends.
You seem to forget that the key cloning machine is always present in everyone's house, so once someone gets inside, he can (and usually will) make himself a brand new key. The original key used to break in is then usually ditched in a deep cold river.

Two things you could do: format your SD card EXT2 and make sure the permissions on the PND and appdata are root writable only; or put the PNDs on the NAND (if you have the space for it) and again make their appdata directories root writable only. Much safer.
Bad idea. Most PNDs will not work if appdata isn't writable. So you will end up running every PND as root.
 
Last edited by a moderator:
I'm not sure that metaphor has much life left in it to be honest.
Well, what I meant to say is that once a malicious code gets root access it can, and usually will, hide the initial breach, and make a nice backdoor for itself in the passwd or sudoers. So you won't be able to say which PND got hacked or who hacked it.
 
Last edited by a moderator:
Well good thing the Pandora has such a spotty WIFI connection, that's security built in.
 
Last edited by a moderator:
Back
Top