Debian Bug report logs - #807992
per user oath files

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: per user oath files

Date: Tue, 15 Dec 2015 00:23:45 -0500

Package: libpam-oath
Version: 2.4.1-1
Severity: wishlist

i find it problematic that the management of the OATH secrets is all
centralised in a single file. it seems to me it would be preferable to
delegate this management to users, the same way we have
`~/.ssh/authorized_keys`.

i suggest checking into `~user/.oath` for a similar format (obviously
ommitting the username, to avoid forging other people's credentials).

could that be considered?

-- System Information:
Debian Release: 8.2
  APT prefers stable
  APT policy: (500, 'stable'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libpam-oath depends on:
ii  libc6           2.19-18+deb8u1
ii  liboath0        2.4.1-1
ii  libpam-runtime  1.1.8-3.1
ii  libpam0g        1.1.8-3.1

libpam-oath recommends no packages.

libpam-oath suggests no packages.

-- no debconf information

Message #10 received at 807992@bugs.debian.org (full text, mbox, reply):

From: Ilkka Virta <itvirta@iki.fi>

To: Antoine Beaupré <anarcat@debian.org>, 807992@bugs.debian.org, Debian Bug Tracking System <submit@bugs.debian.org>

Subject: Re: [OATH-Toolkit-help] Bug#807992: per user oath files

Date: Wed, 16 Dec 2015 13:21:01 +0200

A problem with doing that, is that anything that runs with the user's 
permissions could trivially read the secret key from the user's home 
directory. With SSH keys it's not a problem, since they are _public_ 
keys. Plus, a user could do something stupid, like resetting the OTP 
counter on every login, so they wouldn't need to use a pesky changing 
password, but instead use the same one always...

I think some unix-like systems have per-user password files under /etc, 
so that they don't need setuid-root helpers to access them, but there 
still is some program to sanity check the password the user tries to 
set. (a setgid helper plus some trickery with file and directory 
permissions.) Doing something like that would simplify the backend, but 
of course you'd still need a helper application to access the files.


On 15.12. 7:23, Antoine Beaupré wrote:
> Package: libpam-oath
> Version: 2.4.1-1
> Severity: wishlist
>
> i find it problematic that the management of the OATH secrets is all
> centralised in a single file. it seems to me it would be preferable to
> delegate this management to users, the same way we have
> `~/.ssh/authorized_keys`.
>
> i suggest checking into `~user/.oath` for a similar format (obviously
> ommitting the username, to avoid forging other people's credentials).
>
> could that be considered?
>
> -- System Information:
> Debian Release: 8.2
>    APT prefers stable
>    APT policy: (500, 'stable'), (1, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
> Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages libpam-oath depends on:
> ii  libc6           2.19-18+deb8u1
> ii  liboath0        2.4.1-1
> ii  libpam-runtime  1.1.8-3.1
> ii  libpam0g        1.1.8-3.1
>
> libpam-oath recommends no packages.
>
> libpam-oath suggests no packages.
>
> -- no debconf information
>

-- 
Ilkka Virta <itvirta@iki.fi>

Message #15 received at 807992@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Ilkka Virta <itvirta@iki.fi>, 807992@bugs.debian.org

Subject: Re: [OATH-Toolkit-help] Bug#807992: per user oath files

Date: Wed, 16 Dec 2015 08:44:18 -0500

On 2015-12-16 06:21:01, Ilkka Virta wrote:
> A problem with doing that, is that anything that runs with the user's 
> permissions could trivially read the secret key from the user's home 
> directory. With SSH keys it's not a problem, since they are _public_ 
> keys. Plus, a user could do something stupid, like resetting the OTP 
> counter on every login, so they wouldn't need to use a pesky changing 
> password, but instead use the same one always...
>
> I think some unix-like systems have per-user password files under /etc, 
> so that they don't need setuid-root helpers to access them, but there 
> still is some program to sanity check the password the user tries to 
> set. (a setgid helper plus some trickery with file and directory 
> permissions.) Doing something like that would simplify the backend, but 
> of course you'd still need a helper application to access the files.

Right, you are right of course. I do think it's critical to keep that
file from being readable from random apps. The format *is* also a little
brittle so it seems important to have standardized access as well...

Maybe having a system similar to shadow passwords would be necessary
here: there could be a secret file that can only be read by root (or
with the right caps) and would need a special tool (oath.passwd?) to
reset.

so harder than i thought...

a.
-- 
Si l'image donne l'illusion de savoir
C'est que l'adage pretend que pour croire,
L'important ne serait que de voir
                        - Lofofora

Message #20 received at 807992@bugs.debian.org (full text, mbox, reply):

From: Ilkka Virta <itvirta@iki.fi>

To: Antoine Beaupré <anarcat@debian.org>, 807992@bugs.debian.org

Subject: Re: [OATH-Toolkit-help] Bug#807992: per user oath files

Date: Mon, 21 Dec 2015 23:44:23 +0200

On 16.12. 15:44, Antoine Beaupré wrote:
> On 2015-12-16 06:21:01, Ilkka Virta wrote:
> Right, you are right of course. I do think it's critical to keep that
> file from being readable from random apps. The format *is* also a little
> brittle so it seems important to have standardized access as well...
>
> Maybe having a system similar to shadow passwords would be necessary
> here: there could be a secret file that can only be read by root (or
> with the right caps) and would need a special tool (oath.passwd?) to
> reset.

Well being root-only and having some sort of a helper app is already 
needed. (Though the helper might well be the admins text editor.

As for brittleness, it shares the same thing with all other text files: 
they kind of have to be rewritten completely every time (can't just 
replace a single line). Unless you meant some other brittleness? Of 
course there's locking, per-user files would make that a bit simpler.

This was the per-user shadow file thingy I was thinking of:
http://www.openwall.com/tcb/ (see the slides)

-- 
Ilkka Virta <itvirta@iki.fi>

Message #25 received at 807992@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Ilkka Virta <itvirta@iki.fi>, 807992@bugs.debian.org

Subject: Re: [OATH-Toolkit-help] Bug#807992: per user oath files

Date: Sat, 05 Mar 2016 15:01:39 -0500

On 2015-12-21 16:44:23, Ilkka Virta wrote:
> On 16.12. 15:44, Antoine Beaupré wrote:
>> On 2015-12-16 06:21:01, Ilkka Virta wrote:
>> Right, you are right of course. I do think it's critical to keep that
>> file from being readable from random apps. The format *is* also a little
>> brittle so it seems important to have standardized access as well...
>>
>> Maybe having a system similar to shadow passwords would be necessary
>> here: there could be a secret file that can only be read by root (or
>> with the right caps) and would need a special tool (oath.passwd?) to
>> reset.
>
> Well being root-only and having some sort of a helper app is already 
> needed. (Though the helper might well be the admins text editor.
>
> As for brittleness, it shares the same thing with all other text files: 
> they kind of have to be rewritten completely every time (can't just 
> replace a single line). Unless you meant some other brittleness? Of 
> course there's locking, per-user files would make that a bit simpler.

No that is pretty much it - i was thinking of lock contention issues and
so on.

> This was the per-user shadow file thingy I was thinking of:
> http://www.openwall.com/tcb/ (see the slides)

right. pretty much what i had in mind.

a.

-- 
When I came back to the United States, I decided that if you could use
propaganda for war, you could certainly use it for peace. And
"propaganda" got to be a bad word because of the Germans using it, so
what I did was to try and find some other words so we found the words
"public relations".
                         - Edward Bernays

Message #30 received at 807992@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Ilkka Virta <itvirta@iki.fi>, 807992@bugs.debian.org

Subject: Re: [OATH-Toolkit-help] Bug#807992: per user oath files

Date: Mon, 01 Aug 2016 10:22:59 -0400

On 2016-03-05 15:01:39, Antoine Beaupré wrote:
> On 2015-12-21 16:44:23, Ilkka Virta wrote:
>> On 16.12. 15:44, Antoine Beaupré wrote:
>>> On 2015-12-16 06:21:01, Ilkka Virta wrote:
>>> Right, you are right of course. I do think it's critical to keep that
>>> file from being readable from random apps. The format *is* also a little
>>> brittle so it seems important to have standardized access as well...
>>>
>>> Maybe having a system similar to shadow passwords would be necessary
>>> here: there could be a secret file that can only be read by root (or
>>> with the right caps) and would need a special tool (oath.passwd?) to
>>> reset.
>>
>> Well being root-only and having some sort of a helper app is already 
>> needed. (Though the helper might well be the admins text editor.
>>
>> As for brittleness, it shares the same thing with all other text files: 
>> they kind of have to be rewritten completely every time (can't just 
>> replace a single line). Unless you meant some other brittleness? Of 
>> course there's locking, per-user files would make that a bit simpler.
>
> No that is pretty much it - i was thinking of lock contention issues and
> so on.
>
>> This was the per-user shadow file thingy I was thinking of:
>> http://www.openwall.com/tcb/ (see the slides)
>
> right. pretty much what i had in mind.

Any progress here?

it's still kind of inconvenient to deploy this on multi-user systems
right now... should we write a "choath" to input the user token or split
the file?

a.

-- 
The Net treats censorship as damage and routes around it.
                         - John Gilmore

Message #35 received at 807992-done@bugs.debian.org (full text, mbox, reply):

From: Simon Josefsson <simon@josefsson.org>

To: Antoine Beaupré <anarcat@debian.org>

Cc: Ilkka Virta <itvirta@iki.fi>, 807992-done@bugs.debian.org

Subject: Re: Bug#807992: Bug#807992: per user oath files

Date: Thu, 03 Oct 2024 09:50:59 +0200

[Message part 1 (text/plain, inline)]

Antoine Beaupré <anarcat@debian.org> writes:

> On 2016-03-05 15:01:39, Antoine Beaupré wrote:
>> On 2015-12-21 16:44:23, Ilkka Virta wrote:
>>> On 16.12. 15:44, Antoine Beaupré wrote:
>>>> On 2015-12-16 06:21:01, Ilkka Virta wrote:
>>>> Right, you are right of course. I do think it's critical to keep that
>>>> file from being readable from random apps. The format *is* also a little
>>>> brittle so it seems important to have standardized access as well...
>>>>
>>>> Maybe having a system similar to shadow passwords would be necessary
>>>> here: there could be a secret file that can only be read by root (or
>>>> with the right caps) and would need a special tool (oath.passwd?) to
>>>> reset.
>>>
>>> Well being root-only and having some sort of a helper app is already 
>>> needed. (Though the helper might well be the admins text editor.
>>>
>>> As for brittleness, it shares the same thing with all other text files: 
>>> they kind of have to be rewritten completely every time (can't just 
>>> replace a single line). Unless you meant some other brittleness? Of 
>>> course there's locking, per-user files would make that a bit simpler.
>>
>> No that is pretty much it - i was thinking of lock contention issues and
>> so on.
>>
>>> This was the per-user shadow file thingy I was thinking of:
>>> http://www.openwall.com/tcb/ (see the slides)
>>
>> right. pretty much what i had in mind.
>
> Any progress here?
>
> it's still kind of inconvenient to deploy this on multi-user systems
> right now... should we write a "choath" to input the user token or split
> the file?

Hi!  I am going through bug reports, and noticed this one.  I believe
this was implemented in the 2.6.7 release, long after your original
report and the discussion.  See NEWS entry:

** pam_oath: Support variables in usersfile string parameter.
These changes introduce the ${USER} and ${HOME} placeholder values for
the usersfile string in the pam_oath configuration file. The
placeholder values allow the user credentials file to be stored in a
file path that is relative to the user, and mimics similar behavior
found in google-authenticator-libpam.
The motivation for these changes is to allow for non-privileged
processes to use pam_oath (e.g., for 2FA with
xscreensaver). Non-privileged and non-suid programs are unable to use
pam_oath. These changes are a proposed alternative to a suid helper
binary as well.
Thanks to Jason Graham <jgraham@compukix.net> for the patch.  See
<https://gitlab.com/oath-toolkit/oath-toolkit/-/merge_requests/12>.

Please have a look at the pam_oath README and use the 'usersfile'
setting:

  "usersfile": Specify filename where credentials are stored, for
               example "/etc/users.oath". The placeholder values
               "${USER}" and "${HOME}" may be used to specify the
               filename on a per-user basis. The values "${USER}" and
               "${HOME}" expand to the user's username and home
               directory, respectively.

I believe there are three relevant basic use cases:

1) usersfile=/etc/users.oath - root owned and read/write protected
against end-users, for centralized control.

2) usersfile=${HOME}/.config/oath/secrets - user controlled secrets, for
easy end-user management.  Disadvantage is that user can read their OATH
secret, and potentially damage their ability to login by messing up the
file, but in some situations that may be an advantage.

3) usersfile=/var/oath/oath.${USER}.secrets -- root-controlled per-user
file, typically more relevant for larger multi-user system where you
want to split up the /etc/users.oath file on a per-user basis.

Reading through this bug report makes me believe this is now already
implemented, so I am closing this bug report.  Feel free to re-open if I
missed some important use-case or if you want some other functionality!

/Simon

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.