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
Description: PGP signature
--- End Message ---