Pre Installed Programs


'_VWV_' said:
My security concern was: I'm give an SD card with "some interesting stuff" and when I insert it into Panda the daemon finds "malware.pnd" or rootkit.pnd and happily installs the app without giving me any hint on what's happening. This is a security hole I think. You see, it has nothing to do with "trusted repos". I don't want to say I completely dislike the idea. I just think that the daemon should have minimal privileges and should be hardened against possible privilege escalation. I don't want this windoze shit that works through autorun.ini to be possible on panda.
It won't autorun - it'll just discover the new apps and give you icons in the launcher - you'd still have to manually run these new apps before anything nasty could happen.


Perhaps for security, the daemon could keep track of the hash of each package (i.e. "I remember seeing SomeGame.pnd, which had a hash of "xyz")

The next time you run an app, (or the next time it rescans) it quickly compares the hash, and can give you a warning if the app has changed. That way, if something/someone modifies the pnd without your knowledge, you'll get notification the next time you ran it.

Of course, you'd want an option to turn that off, too :)

Perhaps just overlaying a little "NEW!" splash over the icon would be good - that way it's unobtrusive, but a handy reminder to you that something hasn't been played yet, or a warning that something has changed without your knowledge
 
Last edited by a moderator:
Hash check is a nice idea though it's hard to implement as saves will modify the hash of a .pnd. We could check only the app itself but I really don't know how to implement it in a way that an attacker won't be given a chance to escape the check.
Secondly.. you know.. I trust apt and sudo because literally thousands of eyes are watching carefully. When you try to reinvent a bicycle, the first attitude will be cautious - that's normal I think. On the one hand I see that some people may need such a handheld-oriented app dealing system. But on the other hand panda has 2 SD slots. I thought we could use one SD slot for OS (just to expand the NAND if one wishes stick with pandora OS or as / if one wishes stick with gentoo or ubuntu or whatever). But now I see that 1) the coming OS will solely be based on NAND and 2) devs like the idea of complicated file systems and app daemons so I wish them good luck and will be happy to monitor their progress.
:)
 
Last edited by a moderator:
'_VWV_' said:
Hash check is a nice idea though it's hard to implement as saves will modify the hash of a .pnd. We could check only the app itself but I really don't know how to implement it in a way that an attacker won't be given a chance to escape the check.
Apps should probably save settings in the user home directory on the NAND.
 
Last edited by a moderator:
QUOTE

Hmm.... after reading all this...

Is there or going to be a n00b guide/faq on the many ways to set up your filesystem with advantages and disadvantages, cuz that would be helpful.

I'm gonna have to spend an hour on jeff's first post to understand all of this, so yeah.... On top of that, Linux n00b



I think you got something wrong, you dont have to bother with any of that as a user.

1.) download awesomeapp.pnd from archive.pandora.org to your sd card
2.) insert sd card into pandora
3.) klick on the icon of awesomeapp in the menu.

QUOTE
QUOTE
Hash check is a nice idea though it's hard to implement as saves will modify the hash of a .pnd. We could check only the app itself but I really don't know how to implement it in a way that an attacker won't be given a chance to escape the check.

Apps should probably save settings in the user home directory on the NAND.

Nothing will ever modify a .pnd they are readonly.

All changes to CWD will be redirected to a special folder on the sdcard the pnd is on. (union mount)



Also security isn't really a issue and we dont really care AFAIK.
If the user wants to run a app from a shadey source that may be malicious then theres nothing the system can do about it.
 
Last edited by a moderator:
Monk said:
You have not met some of my clients :shakeshead
Heh... Couldn't be any worse than the pharmacist that'd gotten the wrong media (5.25" as opposed to the 3.5" they were supposed to get) and then proceeded to fold the media into fourths and insert it into his DME management machine...

NEVER underestimate end users. Make something fool-proof and all you do is improve the quality of the fools. :D
 
Last edited by a moderator:
'Vimacs' said:
Nothing will ever modify a .pnd they are readonly.

All changes to CWD will be redirected to a special folder on the sdcard the pnd is on. (union mount)
I won't pretend to really understand all the pnd stuff. If a pnd cannot be modified, how does that work with online apps (or more specifically for me: games) that patch their own content?
 
Last edited by a moderator:
the pnd is mounted to a temporary location (read only)
then we put a union mount over that which redirects all writes (cow) to sdcard/appdata/appidid/ (or sdcard/appdata/appname-uniqueid, we aren't totally sure on that yet)

So when the app tries to write to its own folder or change a file the file actually ends up in the appdata folder.

This results in the pnd always being in its original state, allowing us to use a read only fs image for pnd.
The positive side effect is that you can always just give the pnd to someone else without risking to give him a faulty one or one with private data inside it.

Also you exactly know where all your savestates/configs etc are which makes for easy backups. (as long as every app sticks to CWD)
 
Last edited by a moderator:
There seems to be a downside to that. Correct me if I'm wrong, but say a game has a 100mb large data file, for example an uncompressed zip file containing all the content for the game, then as soon as one of the content files in the zip file inside the pnd is updated the entire file will be cloned. Which means eating up a lot of extra space?

I suppose you could work around that by creating an entirely separate patch receiving mechanism for the Pandora that simply stores the patched content as seperate files, but that also has the problem of every content file taking up additional space on the SD card?

I guess the pnd could simply contain no content whatsoever and downloads the whole thing at first run as a sort of installer as a workaround. I dunno, seems kind of suboptimal to me though.

Not that I don't think the solution isn't clever and wouldn't work very well for plenty of stuff, but thinking about it seems to me it's not universally beneficial.
 
Last edited by a moderator:
I dont know a single game which alters its own data files, any examples?

And if there is such a game, remember that pnd isn't the only option, you can also have normal folders.
 
Last edited by a moderator:
No, most games just have savegames and a small config file for resolution and sound levels.

I would have screamed "RED FACTION!!!" but only people who have played the game would have gotten it, and those are technically part of the saved game anyway. And it's certainly not 100MB of alterations. It clears out each level once you pass through the airlocks.
 
Last edited by a moderator:
I am guessing eniko means something like the mmo she is working on. There could be homebrew that does updates or patches within the game/app. I guess you would have to resort to 'offline' updating though if .pnd files can't be altered while it's running.
 
Last edited by a moderator:
'MDave' said:
I am guessing eniko means something like the mmo she is working on. There could be homebrew that does updates or patches within the game/app. I guess you would have to resort to 'offline' updating though if .pnd files can't be altered while it's running.

I believe (vimacs and skeezix correct me if I'm wrong) that if you put a new executable in the appdata dir, it would also be used instead of the one in the PND bundle, so exec patches is good. For anything else, if the game is already online, it could well download the data files during first use or something and leave them in the appdata dir.

If that isn't any good yet, the game can download a "patcher" or "installer" PND, then execute it (and quit itself of course) to patch the PND file itself to the new version. That might be some interesting addition to libpnd down the road actually--write-support in mounting for patching/updating PNDs (also with access to the PXML area and stuff).
 
Last edited by a moderator:
'Tinnus' said:
I believe (vimacs and skeezix correct me if I'm wrong) that if you put a new executable in the appdata dir, it would also be used instead of the one in the PND bundle, so exec patches is good.
Thats correct.
 
Last edited by a moderator:
Back
Top