GNOME keyring unlocking

2013-10-10 Thread p10
Hello , all ,
I just transitioned from Thunderbird to Evolution + GNOME online
accounts and found out there's one big drawback (at least for me it's
very annoying) - autologin doesn't unlock the keyring . I think I
understand more or less why that's happening , but autologin is useless
if you're going to enter your password after 5 seconds anyway , which
makes this feature incompatible with Online accounts . Now that's what
I consider a serious problem , because most users will prefer to
auto-login and when they encounter the issue - what will they do ?
Search in Google of course ! And the only solution to be found is
turning off encryption (setting a blank password) for the keyring . (not
mentioning the other solution is to continue being frustrated by the
password prompt as long as possible) 

 Now my first question is - how does GDM store the password to autologin
a specific user , when AFAIK the kernel handles user login services and
the passwords there are probably stored in hashes , so GDM needs to give
the kernel the actual password to authenticate the user (other option is
that the kernel has an outologin option , but that doesn't seem like
something Linus would approve) . So if this is the case why can't GDM
unlock the keyring in the same manner it unlocks the user session ?
(sorry for making so much assumptions , hopefully I've stayed in the
lines of what's logical)

Petko

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: GNOME keyring unlocking

2013-10-10 Thread Simon McVittie
On 10/10/13 11:13, p10 wrote:
 autologin doesn't unlock the keyring . I think I
 understand more or less why that's happening

The reason is: libpam-gnome-keyring needs your password to decrypt the
keyring. Without your password, it just doesn't have enough information.

  Now my first question is - how does GDM store the password to autologin
 a specific user

It doesn't. GDM (or at least, enough of GDM) is a privileged process
running as root with full capabilities, and can do whatever it has been
configured to do, including changing its uid to you without asking for a
password first.

Login processes *usually* prompt for, and check, an ordinary password
first - but that's not required. They can equally well use a
one-time-password scheme like OATH[1], query a fingerprint reader[2], or
just say yes regardless[3]. When GDM has been configured to
auto-login, its policy for that user's login is just say yes.

 when AFAIK the kernel handles user login services

The kernel doesn't handle user login services (at least, not on typical
Unix OSs like Linux and *BSD). The kernel allows processes with
appropriate capabilities[4] to become another user. That's all gdm has
to do.

S

[1] more secure than ordinary passwords
[2] not actually very secure
[3] not at all secure
[4] approximately running as root, although on a modern system,
Linux capabilities (POSIX.1e draft capabilities) are also involved

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: GNOME keyring unlocking

2013-10-10 Thread Debarshi Ray
On Thu, Oct 10, 2013 at 01:13:55PM +0300, p10 wrote:
 I just transitioned from Thunderbird to Evolution + GNOME online
 accounts and found out there's one big drawback (at least for me it's
 very annoying) - autologin doesn't unlock the keyring .

Stef had some ideas:
http://www.superlectures.com/guadec2013/more-secure-with-less-security

Cheers,
Debarshi

-- 
Wearing non-prescription glasses and embracing obscurity doesn't
necessarily make you a hipster.  -- Anonymous

pgpFIdyRWBqwu.pgp
Description: PGP signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME keyring unlocking

2013-10-10 Thread p10
Thanks for the explanation , so the problem is not trivial . But it
still stands - people are setting empty passwords to avoid entering a
password every time + the auto-login option becomes practically obsolete
when using the keyring. So where do I further the discussion on that - a
bug , a blueprint ?

Petko

On Thu, 2013-10-10 at 11:33 +0100, Simon McVittie wrote:
 On 10/10/13 11:13, p10 wrote:
  autologin doesn't unlock the keyring . I think I
  understand more or less why that's happening
 
 The reason is: libpam-gnome-keyring needs your password to decrypt the
 keyring. Without your password, it just doesn't have enough information.
 
   Now my first question is - how does GDM store the password to autologin
  a specific user
 
 It doesn't. GDM (or at least, enough of GDM) is a privileged process
 running as root with full capabilities, and can do whatever it has been
 configured to do, including changing its uid to you without asking for a
 password first.
 
 Login processes *usually* prompt for, and check, an ordinary password
 first - but that's not required. They can equally well use a
 one-time-password scheme like OATH[1], query a fingerprint reader[2], or
 just say yes regardless[3]. When GDM has been configured to
 auto-login, its policy for that user's login is just say yes.
 
  when AFAIK the kernel handles user login services
 
 The kernel doesn't handle user login services (at least, not on typical
 Unix OSs like Linux and *BSD). The kernel allows processes with
 appropriate capabilities[4] to become another user. That's all gdm has
 to do.
 
 S
 
 [1] more secure than ordinary passwords
 [2] not actually very secure
 [3] not at all secure
 [4] approximately running as root, although on a modern system,
 Linux capabilities (POSIX.1e draft capabilities) are also involved
 
 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/desktop-devel-list


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: GNOME keyring unlocking

2013-10-10 Thread Milan Bouchet-Valat
Le jeudi 10 octobre 2013 à 14:26 +0300, p10 a écrit :
 Thanks for the explanation , so the problem is not trivial . But it
 still stands - people are setting empty passwords to avoid entering a
 password every time + the auto-login option becomes practically obsolete
 when using the keyring. So where do I further the discussion on that - a
 bug , a blueprint ?
What are you asking for exactly? To encrypt your keyring using a
password you do not need to type at all? ;-)

If you want to secure your keyring, you'll have to type at some point a
secret information that is not stored on the system. If you don't need
to do that, anybody could access your keyring. So that's really not an
implementation issue, that's a logical one.


Regards


 Petko
 
 On Thu, 2013-10-10 at 11:33 +0100, Simon McVittie wrote:
  On 10/10/13 11:13, p10 wrote:
   autologin doesn't unlock the keyring . I think I
   understand more or less why that's happening
  
  The reason is: libpam-gnome-keyring needs your password to decrypt the
  keyring. Without your password, it just doesn't have enough information.
  
Now my first question is - how does GDM store the password to autologin
   a specific user
  
  It doesn't. GDM (or at least, enough of GDM) is a privileged process
  running as root with full capabilities, and can do whatever it has been
  configured to do, including changing its uid to you without asking for a
  password first.
  
  Login processes *usually* prompt for, and check, an ordinary password
  first - but that's not required. They can equally well use a
  one-time-password scheme like OATH[1], query a fingerprint reader[2], or
  just say yes regardless[3]. When GDM has been configured to
  auto-login, its policy for that user's login is just say yes.
  
   when AFAIK the kernel handles user login services
  
  The kernel doesn't handle user login services (at least, not on typical
  Unix OSs like Linux and *BSD). The kernel allows processes with
  appropriate capabilities[4] to become another user. That's all gdm has
  to do.
  
  S
  
  [1] more secure than ordinary passwords
  [2] not actually very secure
  [3] not at all secure
  [4] approximately running as root, although on a modern system,
  Linux capabilities (POSIX.1e draft capabilities) are also involved
  
  ___
  desktop-devel-list mailing list
  desktop-devel-list@gnome.org
  https://mail.gnome.org/mailman/listinfo/desktop-devel-list
 
 
 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/desktop-devel-list

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME keyring unlocking

2013-10-10 Thread Sam Bull
On Thu, 2013-10-10 at 13:13 +0300, p10 wrote:
 if you're going to enter your password after 5 seconds anyway, which
 makes this feature incompatible with Online accounts .

My solution is to use two keyrings. I have a passwordless keyring for IM
and other stuff that is accessed immediately on auto-login.
Then I have a protected keyring that stores the passwords for
Evolution, encrypted folders and other things I want to keep secure.
This means I only need to enter the password when I open Evolution or
something protected, and not immediately everytime I turn the machine
on. Which also means I can give it to a friend and let them browse the
internet or whatever without worrying about them accessing private data.

You seem to be under the impression that auto-login should in some way
be just as secure, without any form of authentication. If you don't need
to enter a password, then it doesn't matter what technical wizardry you
use to unlock the keyring, all someone needs to do is turn your computer
on, and they have full access to your stuff.
You must either choose to have your data protected or unprotected.
Using the two keyring mechanism, like me, you can choose that on a more
fine-grained level, rather than having to make everything unprotected
though.


signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.12 features: better integration with Facebook and Windows Live

2013-10-10 Thread Andres Fernandez
El 10/10/2013 03:02, fr33domlo...@mailoo.org escribió:

 Hello,

 Is there any plan to add support for MediaGoblin and Diaspora

Diaspora doesn't have a public API yet.

Andrés Fernandez
Software Peronista
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME keyring unlocking

2013-10-10 Thread Michael Catanzaro
On Thu, 2013-10-10 at 14:21 +0200, Milan Bouchet-Valat wrote:
 What are you asking for exactly? To encrypt your keyring using a
 password you do not need to type at all? ;-)

But he's right: autologin is useless right now, unless somehow you've
managed to never use the keyring by having no wireless networks, no
online accounts, no Internet passwords (if you use Epiphany), no email
accounts in Evolution


signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.12 features: better integration with Facebook and Windows Live

2013-10-10 Thread fr33domlover
Then what about MediaGoblin?

Anyway, there's a chance Diaspora develops a public API if you talk to
them and explain they're going to have a desktop plugin in GNOME. I'm
sure they'll be happy. So the only question is whether someone wants to
develop a plugin once Diaspora has the API.

On ה', 2013-10-10 at 10:43 -0300, Andres Fernandez wrote:
 
 El 10/10/2013 03:02, fr33domlo...@mailoo.org escribió:
 
  Hello,
 
  Is there any plan to add support for MediaGoblin and Diaspora
 
 Diaspora doesn't have a public API yet.
 
 Andrés Fernandez
 Software Peronista
 
 


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME keyring unlocking

2013-10-10 Thread Dominique Leuenberger a.k.a. Dimstar


Quoting Michael Catanzaro mcatanz...@gnome.org:


On Thu, 2013-10-10 at 14:21 +0200, Milan Bouchet-Valat wrote:

What are you asking for exactly? To encrypt your keyring using a
password you do not need to type at all? ;-)


But he's right: autologin is useless right now, unless somehow you've
managed to never use the keyring by having no wireless networks, no
online accounts, no Internet passwords (if you use Epiphany), no email
accounts in Evolution


Would you recommend to 'automatically' create a keyring without a  
password for autologin users?
This is in fact what you need in this case (and the user CAN remove  
the password... and thus AGREE to not protect his passwords.. I don't  
think we should falsely just not have a password and accept that the  
'user chose to autologin and probably does not care for his secrets'.


Dominique
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: GNOME keyring unlocking

2013-10-10 Thread Michael Catanzaro
On Thu, 2013-10-10 at 16:41 +0200, Dominique Leuenberger a.k.a. Dimstar
wrote:
 Would you recommend to 'automatically' create a keyring without a  
 password for autologin users?

I think it's a matter of sane defaults. I do think automatic login
clearly implies that the user does not want to type a password when logs
in, and if he does, then the setting is broken, period. It seems to
follow that passwords for stuff that run at login should be stored
unencrypted if the user is using automatic login. If we were to somehow
implement that, we would probably want to warn the user about the
security implications, of course. (Or maybe the user has LUKS encryption
and really doesn't need to type a password twice.)

I missed the distinction between login tasks (wireless networks,
Telepathy accounts) and non-login tasks (web/email passwords) that Sam
Bull has pointed out. So maybe non-login-related passwords could still
be protected by default.


signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.12 feature: polari

2013-10-10 Thread Florian Müllner
On Fri, Oct 4, 2013 at 3:33 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
 Do you have something like a roadmap for what you hope to have in 3.12 ?

I have just added one at https://wiki.gnome.org/Apps/Polari/Roadmap;
there is only one item that isn't either small or doesn't have some
initial code, so it should be quite doable in the 3.12 timeframe.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: 3.12 feature: polari

2013-10-10 Thread Allan Day
Kenneth Nielsen k.nielse...@gmail.com wrote:
 I don't mean to be a buzz kill here but IRC clients seem to be dime a dozen.

Can you give a list of dedicated IRC clients for GNOME? How many of
them are any good?

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: GNOME keyring unlocking

2013-10-10 Thread Sam Bull
On Thu, 2013-10-10 at 10:28 -0500, Michael Catanzaro wrote:
 I missed the distinction between login tasks (wireless networks,
 Telepathy accounts) and non-login tasks (web/email passwords) that Sam
 Bull has pointed out. So maybe non-login-related passwords could still
 be protected by default.

Something I've been thinking about, is if we used 2 keyrings by default,
one unprotected and one protected. Then in the password dialog, we could
have a radio button like:

x Don't store this password
   Store this password for later:
x Unprotected (or 'Unlocked at login')
x Using my master password

Or some wording along those lines. The unprotected one is the login
keyring, which is technically still protected if you login, but has no
protection if you autologin.

Then the master password one is a second keyring with a separate
password. This can then still be used by regular login users as a way of
adding an extra layer of security.

I'd be interested in working on this, but I don't have the time to spare
at the moment.


signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME keyring unlocking

2013-10-10 Thread Sam Bull
On Thu, 2013-10-10 at 20:12 +0300, p10 wrote:
 The problem
 is that if someone manages to hack his way into my account/computer (say
 there's some SSH/VNC/Bittorrent sync/whatever else vulnerability) I
 don't want my passwords in plain text.
 
 if you unlock the
 keyring every user-space app can access the stored passwords . (?) 
  Ideally certain apps would get access to certain keys .

Right, that is what I was getting at. If the keyring is unlocked, they
are going to have full access to it, regardless of how they get in.

Stef has been talking about storing the keys with each individual
application, which will improve the situation, as apps won't be able to
get other apps passwords.
But, I don't believe root is involved. So, if they are actually logged
into your account, via SSH or something, then I presume they would still
have full access to that information. (Otherwise, how would the user be
able to manage their own keyring?)


signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME keyring unlocking

2013-10-10 Thread Simon McVittie
On 10/10/13 18:12, p10 wrote:
 That's my current security setup - a user account that I use for
 everything , and 'su' into root with a password I don't keep stored
 anywhere

If you type your root password into a gnome-terminal running with user
privileges, a shell running with user privileges, etc., then your user
account is root-equivalent to a determined attacker (for instance, other
user processes could ptrace the gnome-terminal or shell, or put a
keylogging 'su' wrapper in the $PATH).

If you want real privilege separation, you'll need to log in as root (or
as a separate administrative account) via something more privileged than
your user account (e.g. gdm, or getty(8)/login(1) on a text-mode virtual
console).

 if a root service unlocks
 the key-ring for all the user-space programs - there's no point in
 having the system in the first place . So that is a problem that if I'm
 not mistaken stands with the current setup too - if you unlock the
 keyring every user-space app can access the stored passwords .

gnome-keyring does not protect you from your own user session. Security
is meaningless without a security model, and gnome-keyring's security
model is https://wiki.gnome.org/GnomeKeyring/SecurityPhilosophy.

When applications within a user session can be protected from each
other, it will make sense to develop a new security model. I don't think
we're there yet.

S

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: 3.12 features: better integration with Facebook and Windows Live

2013-10-10 Thread Andres Fernandez


Hi, fr33domlover

El jue, 10 de oct 2013 a las 11:29 , fr33domlover 
fr33domlo...@mailoo.org escribió:

Then what about MediaGoblin?

Anyway, there's a chance Diaspora develops a public API if you talk to
them and explain they're going to have a desktop plugin in GNOME. I'm
sure they'll be happy.



Well, I'm not involved on Diaspora development, but AFAIK there is an 
API dicussion in loomio[1]. The API is a long desire feature, but it is 
not ready yet. 


[1] https://www.loomio.org/discussions/6930

Best regards,

Andres Fernandez
Software Peronista

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list