Re: GNOME keyring unlocking

[p10]

Very good points . It seems I have a lot more to read on linux
security .

On Thu, 2013-10-10 at 19:01 +0100, Simon McVittie wrote:
> 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 .
> 
> 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


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

Re: GNOME keyring unlocking

[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 .

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: GNOME keyring unlocking

[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

[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

[p10]

On Thu, 2013-10-10 at 14:05 +0100, fox_aaawkq wrote:
> 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.

The idea is that nobody has physical access to my machine . It's at
home , it doesn't have some nuclear-rocket-schematics-like information ,
and that's why I'm not afraid to leave automatic login on . 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. So here's the use cases : 
1.Full security , no decryption keys stored on the computer in any form
- the encrypted stuff cannot be decrypted even if someone takes your
computer physically and examines it.
2.Sanitary root space , not so air-tight user space - assuming the
machine is not going to get physically stolen the active account is
non-administrative in theory no bad code is going to have root
clearance . So the keyring in user-space can be encrypted by a key in
root-space , handled by a trusted program on startup.

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 , so that even if I happen to execute bad code , or get my
account password otherwise hacked the attacker is confined to that
user-space. 

Now the problem from here on is the following (I thought I had it
figured out but I caught my own bad logic) : 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 . (?) 
 Ideally certain apps would get access to certain keys .

Petko

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

Re: GNOME keyring unlocking

[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: GNOME keyring unlocking

[Dominique Leuenberger a.k.a. Dimstar]

Quoting 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


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

[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: GNOME keyring unlocking

[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: GNOME keyring unlocking

[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

[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

[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

[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

GNOME keyring unlocking

[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