Active Topics
-
Camera phone competition March 2023 "Endless" (35)
to General by Maemish - 2 days, 20 hrs ago -
TLS 1.2 for N9 is ready (28)
to MeeGo / Harmattan by smartblu9 - 2 days, 21 hrs ago -
Maemo repository (3)
to Community by torsen - 3 days, 12 hrs ago -
Error after installing Leste on sdcard (11)
to Maemo 7 / Leste by Maemish - 4 days, 10 hrs ago -
Introducing ubiboot N9 (multiboot OS loader) (1,393)
to Alternatives by smatkovi - 5 days, 16 hrs ago - more...
|
2010-10-07
, 14:50
|
|
Posts: 1,341 |
Thanked: 708 times |
Joined on Feb 2010
|
#2
|
To be really secure, it should be based on TrueCrypt or similar.
Having every application installed in its own TrueCrypted virtual disk and (un)mounting them with passwords of groups of passwords.
Edit:
"passwords of groups of passwords."
What I mean by this, is every virtual disk (application) has its own automatically randomly generated strong password. There is a applock-password manager, where one can make any number and combination of groups of passwords and then give some own password for every group.
Also there is one master root-password which would open all passwords in the manager and would give ability to create/modify/destroy groups.
When some group is "opened" with the group-password, then the applock-password-manager would mount the corresponded TrueCrypted virtual disks with the passwords of that group. The system would unmount them optionally with selected timeout or manually.
Actual application binaries and their private resource datafiles are in these crypted virtual disks. In /usr/bin/ there is a softlink to the real program inside the virtual disk:
ln -s /mnt/applock/someapp/usr/bin/someapp /usr/bin/someapp
To be really practical, a package manager should support this system.
Also integrating SELinux or apparmor to this would not hurt. Every application would really run in its own sandbox and potential trojan horses couldn't mess outside of their sandbox.
Idea (c) GPLv3
Last edited by zimon; 2010-10-07 at 15:16.
Having every application installed in its own TrueCrypted virtual disk and (un)mounting them with passwords of groups of passwords.
Edit:
"passwords of groups of passwords."
What I mean by this, is every virtual disk (application) has its own automatically randomly generated strong password. There is a applock-password manager, where one can make any number and combination of groups of passwords and then give some own password for every group.
Also there is one master root-password which would open all passwords in the manager and would give ability to create/modify/destroy groups.
When some group is "opened" with the group-password, then the applock-password-manager would mount the corresponded TrueCrypted virtual disks with the passwords of that group. The system would unmount them optionally with selected timeout or manually.
Actual application binaries and their private resource datafiles are in these crypted virtual disks. In /usr/bin/ there is a softlink to the real program inside the virtual disk:
ln -s /mnt/applock/someapp/usr/bin/someapp /usr/bin/someapp
To be really practical, a package manager should support this system.
Also integrating SELinux or apparmor to this would not hurt. Every application would really run in its own sandbox and potential trojan horses couldn't mess outside of their sandbox.
Idea (c) GPLv3
Last edited by zimon; 2010-10-07 at 15:16.
|
|
2010-10-07
, 15:20
|
|
Posts: 96 |
Thanked: 51 times |
Joined on Jul 2010
@ India
|
#3
|
Originally Posted by zimon
Idea is great. but please note the usage scenario I mentioned, for such a case, encryption isnt really necessary.
To be really secure, it should be based on TrueCrypt or similar.
Having every application installed in its own TrueCrypted virtual disk and (un)mounting them with passwords of group of passwords.
Edit:
"passwords of group of passwords."
What I mean by this, is every virtual disk (application) has its own automatically randomly generated strong password. There is a password manager, where one can make any number and combination of groups of passwords and then give some own password for every group.
Also there is one master root-password which would open all passwords in the manager and would give ability to create/modify/destroy groups.
When some group is "opened" with the group-password, then the password-manager will mount the corresponded TrueCrypted virtual disks. Would unmount them optionally with selected timeout or manually.
Actual application binaries and their private resource datafiles are in these crypted virtual disks. In /usr/bin/ there is a softlink to the real program inside the virtual disk:
ln -s /mnt/applock/someapp/usr/bin/someapp /usr/bin/someapp
To be really practical, a package manager should support this system.
Idea (c) GPLv3
Your idea may be useful, for example, when we give the devide to a service centre or someone who is an expert in the maemo commant line..
The usage scenario I mentioned are the "common" people who needs a "GUI" for everything.
By the way, why isnt there a truecrypt application for the N900 (apart from the command-line tool, something with a GUI) I've heard of the easycrypt frontend for maemo, but that I believe is for the N8x0 devices..
|
|
2010-10-07
, 15:31
|
|
Posts: 388 |
Thanked: 842 times |
Joined on Sep 2009
@ Finland
|
#4
|
Originally Posted by warhawk007
If application launch dbus signals could be intercepted before they reach their destination (until approved by the locking app), it could be enough to prevent launching an application from the UI... Unless there's an application which calls the binaries directly... or allows defining and running custom shell commands.
Idea is great. but please note the usage scenario I mentioned, for such a case, encryption isnt really necessary.
Your idea may be useful, for example, when we give the devide to a service centre or someone who is an expert in the maemo commant line..
The usage scenario I mentioned are the "common" people who needs a "GUI" for everything.
It could work for this purpose, but it definitely could not be called secure.
|
|
2010-10-07
, 15:31
|
|
Posts: 1,341 |
Thanked: 708 times |
Joined on Feb 2010
|
#5
|
Originally Posted by warhawk007
Never underestimate the "common" people.
The usage scenario I mentioned are the "common" people who needs a "GUI" for everything.
The famous "script kiddies" are those "common" people also, and all those owners of zombie bots in the DDOS-botnetworks.
|
|
2010-10-07
, 15:50
|
|
Posts: 96 |
Thanked: 51 times |
Joined on Jul 2010
@ India
|
#6
|
Originally Posted by zimon
:-) I'm not underestimating common people.....I was referring to the particular scenario.....a person in your vicinity who borrows the phone, for example, a friend or neighbor who borrows our phone to listen to music, but gets a bit curious or "nosey" and tries to peek into our conversations or emails. And thats when the hidden background process identifies that a protected application is being opened and prompts the user to enter a password to "open" the particular application, the password which our nosey friend doesnt know.
Never underestimate the "common" people.
The famous "script kiddies" are those "common" people also, and all those owners of zombie bots in the DDOS-botnetworks.
This is the basic requirement. But what app locker does is, simply hide the shortcut to the selected application from the menu and isnt even aware of whether the application is opened or not.
I hope you got my point. This is the most basic requirement. A hidden daemon which runs in the background and identifies when a protected application is being opened and triggers a password prompt to continue. Here, encryption isnt really necessary. Moreover, this basic requirement may be easier for a developer to start with. Features like on-the-fly encryption which may require lots of programming and time to implement may be added later in an update.
:-)
|
|
2010-10-07
, 16:54
|
|
Posts: 96 |
Thanked: 51 times |
Joined on Jul 2010
@ India
|
#8
|
Originally Posted by orion88freedom
I'm not a programmer, so please correct me if I'm wrong.
Getting an app like this will be like a scientist getting a nobel peace prize. Sorry, couldn't think of another suitable analogy.
The basic idea for such an application would be a frontend like applocker which maintains a list of all the applications on the phone and the basic algorithm for the daemon would be..
If selected application = protected application
trigger password prompt
else, launch application
if entered password is correct, launch the application
else, display "Incorrect password" and terminate the appication before launch.
I'm not a programmer, this may not be this easy or my idea may be incorrect. Please do correct me.
|
|
2010-10-07
, 16:54
|
|
Posts: 1,341 |
Thanked: 708 times |
Joined on Feb 2010
|
#9
|
Actually, if Maemo5 (or Meego will) would support SELinux, pretty secure system could be done much more easily and without having (slowish and battery consuming) multiple TrueCrypted virtual disks.
The above TrueCrypt based sandboxing would be like recreating SELinux again but with little different features and by different methods.
If the root-user can decrypt every virtual disk anyway through the applock-password-manager, then just having everything else but /boot in one single crypted volume and having enforced SELinux policy would be better system, because SELinux has extra features.
To port SELinux to maemo5 is doable and would benefit in many other use cases.
Then one could just give and drop priviledges as a root user in xterminal (or in SELinux Policy GUI) before one gives a phone to a neighbour.
The above TrueCrypt based sandboxing would be like recreating SELinux again but with little different features and by different methods.
If the root-user can decrypt every virtual disk anyway through the applock-password-manager, then just having everything else but /boot in one single crypted volume and having enforced SELinux policy would be better system, because SELinux has extra features.
To port SELinux to maemo5 is doable and would benefit in many other use cases.
Then one could just give and drop priviledges as a root user in xterminal (or in SELinux Policy GUI) before one gives a phone to a neighbour.
|
|
2010-10-07
, 17:23
|
|
Posts: 46 |
Thanked: 41 times |
Joined on Jun 2010
|
#10
|
Would it be possible to hack Maemo to make it a multi-user environment?
After all, Maemo is Linux and it comes with all the tools for multi-user access control that are standard in linux. By default, there is just one interactive user "user". However, I'm sure you can modify the configuration files and add other users with a different home directory.
It can work like this: Each additional user get its own home directory. They get read permissions to "opt" and a symbolic link from their directory, and read+write permissions to a specific directory within MyDocs. They do not get permissions to install any new applications. They can run any existing application, but it would use different data (different phonebook, conversations etc.).
You can have an app for switching users, requiring a password. After using it, the user can choose which user to login to after the next restart.
Just an idea.
After all, Maemo is Linux and it comes with all the tools for multi-user access control that are standard in linux. By default, there is just one interactive user "user". However, I'm sure you can modify the configuration files and add other users with a different home directory.
It can work like this: Each additional user get its own home directory. They get read permissions to "opt" and a symbolic link from their directory, and read+write permissions to a specific directory within MyDocs. They do not get permissions to install any new applications. They can run any existing application, but it would use different data (different phonebook, conversations etc.).
You can have an app for switching users, requiring a password. After using it, the user can choose which user to login to after the next restart.
Just an idea.
In this case, the hidden applications can still be opened some or the other way. For example, if I hide the Conversations application, It can still be opened via the phone application, i.e, click contact and create sms. This doesnt offer true privacy.
Instead, can an application be developed which runs in the background as a daemon or process...which can trigger a password prompt when a locked application is launched? This is a better solution in terms of privacy as it truly "locks" the selected application from launching in any way, rather than just hiding the application icon from the menu.
Usage scenario: a friend or neighbor borrows your phone....but you dont want them to see your personal data such as your contacts, conversations, e-mails, etc
A similar application is available for Symbian, Advanced Device Locks.....I hope a previous symbian user knows this.
So any kind developers here who would create such an application for maemo??
Also note, the application lock daemon should launch everytime on phone boot and should also trigger a password prompt when trying to uninstall..
I hope such an application can be developed. Or maybe if applocker can be modified to run this way.