Ubuntu QA:
BlogBrainstormPackage status
Log in
Ubuntu QA
Gnome
Idea sandbox Idea sandbox
Popular ideas Popular ideas
Ideas in development Ideas in development
Implemented ideas Implemented ideas

Popular ideas Here are the latest ideas about Gnome that have been approved.

Let Gnome Keyring unlock itself by checking other Pam modules  
Written by mdhunn the 10 Nov 10 at 20:36. New
Using password less Pam modules for login, sudo, & etc cannot currently unlock the Gnome keyring, causing users to have to enter a password anyway. Aside from the convenience and security benefits of being able to fully use a fingerprint scanner or facial recognition, providing a mechanism to use other Pam modules may have accessibility benefits user who have difficulty typing or remembering passwords.
1
votes
up equal down
Solution #1: Patch Gnome Keyring
Written by mdhunn the 10 Nov 10 at 20:36.
Patch the keyring to allow it to see if sudo, screensaver, or gdm successfully authenticated in the last 5 minutes. If the test fails it should be allowed to run gksu to verify the current users identity.

Add a comment or propose a solution >>

Someone may force you to give up your password  
Written by thorx89 the 26 Sep 10 at 12:17. New
A user with sensitive data on their computer may be coerced into giving up their login password.
In that case, the Private folder or the home folder encryption provided by Ubuntu are no good.
-6
votes
up equal down
Solution #1: Allow a 2nd password that would trigger a specified script when used
Written by thorx89 the 26 Sep 10 at 12:17.
The user could be provided with a means to set up a second, emergency password.
Using this password would not result into a regular login, but it would trigger a specified script instead, first.
This script could then take care of any sensitive data (rename, archive, encrypt, transmit, delete) and if the mechanism is set to login after the execution of the script, the script would then be deleted and the system set to one password only so as to dismiss any idea of an irregular login having taken place.

This might be fairly easy to implement, too.

See the 12 comments or propose a solution >>

Preventing unwanted eyes prying on confidential information   forum
Written by humphreybc the 29 Oct 09 at 03:31. New
Despite needing to enter your root password to alter such basic things as CPU Scaling, you are not once prompted to enter it to access the Passwords and Encryption Keyring. Anyone is able to view your stored MSN, Twitter, email and Wifi passwords in four simple clicks of the mouse from the desktop.

How to reproduce:

1. Restart your computer and login. Do not enter any passwords after your desktop has loaded.

2. Go to Applications > Accessories > Passwords and Encryption Keyrings

3. Click on the 'Login' folder to drop down and view the programs that store data here.

4. Double click on something you want to look at.

5. Click Password to show some dots, then uncheck the box below the dots marked "Show password"

6. Note that throughout this whole procedure, not once were you prompted to enter in anything that verifies you are authorized to view this information.

This is a security risk, and, because it is a conscious decision for design, not classified as a bug.

Here's the related Ubuntu Forums thread:
http://ubuntuforums.org/showthread.php?t=1302342

and, a post on omgubuntu.co.uk:

http://www.omgubuntu.co.uk/2009/10/security-issue-in-gnome-lets-anyone-see.html

[....]
18
votes
up equal down
Solution #1: Prompt to enter user password before showing stored passwords in clear text
Written by humphreybc the 29 Oct 09 at 03:31.
The Seahorse program should prompt you to enter in your user password, much the same way that sudo works, before allowing the stored passwords to be displayed in clear text.

Also, the "Passwords and Encryption Keys" Application should be moved to Preferences.
10
votes
up equal down
Solution #2: Unify Ubuntu personal security.
Written by snkiz the 29 Oct 09 at 04:11.
this is my thought on how to fix it.

The way I see it Ubuntu is almost there, seahorse does ask permission
just no confirmation. And we do have the tools like gconf. And
policykit, witch can handle non-root permissions and IMO is way under
used.

Here's my idea, create a sane list of default apps that can access
seahorse. The ability to change that list through gconf, and
permission checks through policykit for unexpected apps, changing info
or viewing passwords. And finally come up with a unified personal
security policy for the desktop as a whole. (IN about me you need your
password to change your password and about me does not display clear
text.)
0
votes
up equal down
Solution #3: Don't show passwords in plain text
Written by daithi the 27 Nov 09 at 03:04.
Why is there even an option to show passwords in plain text from within a GUI application? This option should be removed, especially if the other solutions are likely to be difficult to implement in practice.
0
votes
up equal down
Solution #4: Require user password before showing passwords in keyrings
Written by zorkerz the 2 Dec 09 at 03:15.
The Seahorse program should prompt you to enter in your user password, much the same way that sudo works, before allowing the stored passwords to be displayed in clear text.

Note: this is the same as solution #1 except that the seahorse launcher "Passwords and Encryption Keys" should remain under applications.
-2
votes
up equal down
Solution #5: Temporary Solution: Educate people
Written by agrouo the 15 Dec 09 at 01:56.
When using a graphical tool for key management (e.g. seahorse) for the first time, tell the people that their passwords and account are generally not safe and they should resort to locking their session and let others use the easily accessible guest account.

(not denying the bigger, but most probably quite harder problem, of securing passwords)
-1
votes
up equal down
Solution #6: Authentication service instead of password store
Written by agrouo the 15 Dec 09 at 02:37.
Generally switch to a better security scheme than passwords. Especially, where no direct user interaction is necessary.

Aims
* preventing programs from accessing passwords of other programs
* avoid using passwords as far as possible

How
* if possible use mechanisms without passwords (e.g. mail account AUTH DIGEST)
* reconstructing passwords should happen in different applications

This consists of three parts:
1) allow programs to let the service handle authentication for them (e.g. mail program lets the authentication service handle AUTH DIGEST authentication, so it doesn't need to see the password at all)

2) restrict access to stored information to the right programs (see Solution #2)

3) For applications which need to use password: instead of storing user-entered passwords to be accessed by the application, store keys which the application needs for decrypting the real passwords.
In this way, attacks would have to be crafted for specific applications, not only against the password store.


Add a comment or propose a solution >>

Small gnome password applet.  
Written by danielpublicsweden the 8 Aug 09 at 20:29. New
Since it seems like people are using the same passwords half across the internets and maybe even their own computer. :(

I would like to see a gnome applet that:

1. You use a master password. (One good, strong password to remember!) Even if this password is compromised, and thanks to the use of "description values", if this password is "lost", it do not threaten all your passwords.
You could even have an extra description values like "sausage"/"flower"/"badger", to get even higher security.

2. Generates your password through algorithms and descriptions on what you use it for. Site url/file/tags/etc. Plus possibilty to use extra personal values for heightened security.

3. _No storage_ of any passwords on disk. (No need for backup) Only descriptions is stored in a encrypted file. (See solution #2)

4. Should be easy to generate new strong passwords.

5. Should be able to autocomplete.

6. Should be useful when using another computer (Public/job) by use of "online" script, which is run locally from browser. Which is achieved by masterpassword + descriptions (as in the url+username/other values, for the site to access) As in: http://passwordmaker.org/passwordmaker.html

How it could work:
The password to use are generated by a master password and "description values" (url/username/tags/file/date/etc.) -> one way hash algorithm ( http://en.wikipedia.org/wiki/Cryptographic_hash_function )= message digest( http://www.rsa.com/rsalabs/node.asp?id=2176 )=password to use. READ ON PLEASE! :D

[....]
2
votes
up equal down
Solution #1: Passwordmaker
Written by danielpublicsweden the 8 Aug 09 at 20:29.
Maybe inner workings of applet _based_ on something like this approach?

http://passwordmaker.sourceforge.net (GPL)
2
votes
up equal down
Solution #2: Passwordmaker and "description values/autocomplete" backup.
Written by danielpublicsweden the 9 Aug 09 at 07:25.
Since the description values of the "file/url/tag/etc." is a big part for generating the password through the one-way hash algorithm. (masterpassword+description values=message digest=password)
Its maybe not easy to remember exactly what values that was used for generating the password.
How could/should the backup be performed?

Suggestion: Compress it with in a encrypted LZMA (7zip), upload it to some site, put a generated password on it, upload function something like the excellent FEBE (http://customsoftwareconsult.com/extensions/febe/febe.html ), which uses http://box.net . Upon addition of autocomplete/generation of new password, give reminder of backup. As in: "Do you want to backup and upload now?"/"Remind me in x days".

See the 3 comments or propose a solution >>

Files in a VFAT file system should be mounted read-write only  
Written by Living-FOSS-iL the 11 Jun 09 at 23:58. New
Files in a VFAT file system should by default be mounted read-write only. At present files in a VFAT file systems are mounted with [r]ead-[w]rite-e[x]ecute permissions for the current user. In technical language the permissions on the file are set to 755 (rwx for the current user and rx for other users).

This simply doesn't make sense. Nobody in his right mind would distribute, if ever needed, Linux executables inside a VFAT file system (ext* will probably be used). On the other hand Wine, the main program used to execute Windows binaries in Linux, doesn't require such permissions.

Since the dominant use of VFAT is for flash drives, I suggest that the files that will be read off such a drive should be mounted by default without execute permissions. It is the safer thing to do when a file system doesn't allow the explicit designation of Unix-style file permissions.
-13
votes
up equal down
Solution #1: Specify fmask=111 for VFAT
Written by Living-FOSS-iL the 11 Jun 09 at 23:59.
There's actually a simple mount option to ensure that permissions for VFAT files are set to read-write only: fmask=111.

A non-root but commandline example of this:

gnome-mount --extra-mount-options fmask=111 -d /dev/sdb1

This IMHO should be made the default if there is no way to explicitly detect whether a file is an executable (user-friendly focus) or if the intention is to prevent the execution of malware (security focus).
3
votes
up equal down
Solution #2: Support other file systems on removable media
Written by Akerbos the 16 Jun 09 at 11:26.
For example, add a program that formats the most part of such a medium with ext3 but adds a little FAT/NTFS partition containing ext3 drivers for Windows. If this is a no-brainer on Ubuntu, people will probably use it.

I have seen this, it seems to work well.

See the 7 comments or propose a solution >>

disk settings in admin menu  
Written by ways the 3 Dec 08 at 09:06. New
the administration menu/control center needs an option called disks, drives, harddrives or storage. this should give you access to boot menu, partitions, filesystems, swap, mount options, encryption and options for secure deleting / cleanup.
18
votes
up equal down
Solution #1: Auto-generated solution of idea #16170
Written by ways the 3 Dec 08 at 09:06.
Ubuntu Brainstorm was updated in January 2009. Since the idea #16170 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

See the 1 comments or propose a solution >>

Secure the menu  
Written by ragnarmoberg the 28 Aug 08 at 11:34. New
It is quite easy to trick the user into running a bad script in sudo by changing the gnome menu from "gksu /usr/sbin/synaptic" to "gksu /home/user/.roughescript.sh".

In a desktop environment using sudo you should need to enter your password in order to change the menu.

Sorry if i misspelt something; English is not my native language.
63
votes
up equal down
Solution #1: Auto-generated solution of idea #12629
Written by ragnarmoberg the 28 Aug 08 at 11:34.
Ubuntu Brainstorm was updated in January 2009. Since the idea #12629 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

See the 15 comments or propose a solution >>

make gnome-keyring more usable and secure  
Written by Hawke the 10 Jul 08 at 22:29. New
Currently, if an app can use gnome-keyring to store a password, there is no way the app can ask gnome-keyring if the key is currently on the keyring, without unlocking it (and exposing all the passwords).

The upshot of this is: Any app which can use gnome-keyring is constantly pestering the user to unlock the keyring, even if the key isn't stored there. If the user gives in to this badgering and unlocks his or her keyring ("See, stupid app, there's no password for you in my keyring!!"), then all the passwords that ARE in the keyring become insecure. And the app still needs to prompt for the password anyway!
36
votes
up equal down
Solution #1: Allow applications to query the keyring to find out if they have a stored key
Written by Hawke the 10 Jul 08 at 22:29.

It would be much nicer (both user-friendly and secure) if an app could query the keyring to find out if it has any passwords stored, rather than demanding that the user unlock the keyring. This way, the only time the keyring would need to be unlocked is *when it was actually going to be used*, thus keeping both users' passwords and sanity safer. Users wouldn't have keep track in their heads of which passwords are stored in the keyring to decide whether to unlock the ring or not, because the only time they'd get a prompt is when the key is there!

I know someone will say "but it's so insecure to have a list of what passwords are stored in the keyring!". But it's just as insecure (or more so) to have the system harangue the user into opening the keyring by default (see libpam-keyring) or unlocking the keyring "just in case" some random app happens to have stored something there (networkmanager is a particularly good one for this) and thereby exposing not just the list of available passwords, but the passwords themselves!

See the 4 comments or propose a solution >>