[Thinkfinger-devel] [PATCH] add ACL to .bir file

[William Jon McCann]

Hi,

Here is a patch to add an ACL to the .bir file so that the user it
belongs to can always read it. I think this is a bit better than
making it owned by the user so that it can't be removed or tampered
with.

Having the file readable by the user it belongs to makes it easier to
support programs that don't run as root - like screensavers.

What do you think?

Thanks,
Jon

[Timo Hoenig]

Hi Jon,

Post by William Jon McCann
Here is a patch to add an ACL to the .bir file so that the user it
belongs to can always read it. I think this is a bit better than
making it owned by the user so that it can't be removed or tampered
with.
Having the file readable by the user it belongs to makes it easier to
support programs that don't run as root - like screensavers.
What do you think?

(I'm replying to both of your mails with this)

Thanks for the patches.

The idea sounds fine in general but I have reason why I haven't gone the
path making the device accessible to users.

Without modifications the USB device is only accessible for root and
setuid binaries. If we loosen that requirement any user can claim the
USB device. Once claimed another user -- or even the system
administrator -- can not claim the device anymore. That's why I am
strongly against making the device accessible to anyone.

In my opinion we should follow some sort of an 'at_console' approach.
We've discussed the start for that in the thread '[resubmit PATCH] Patch
to pretend remote users' [1].

Once this is in, we can discuss if it is really necessary to make the
device accessible to users.

[William Jon McCann]

Hi Timo,

Post by Timo Hoenig
Hi Jon,

Post by William Jon McCann
Here is a patch to add an ACL to the .bir file so that the user it
belongs to can always read it. I think this is a bit better than
making it owned by the user so that it can't be removed or tampered
with.
Having the file readable by the user it belongs to makes it easier to
support programs that don't run as root - like screensavers.
What do you think?

(I'm replying to both of your mails with this)
Thanks for the patches.
The idea sounds fine in general but I have reason why I haven't gone the
path making the device accessible to users.
Without modifications the USB device is only accessible for root and
setuid binaries. If we loosen that requirement any user can claim the
USB device. Once claimed another user -- or even the system
administrator -- can not claim the device anymore. That's why I am
strongly against making the device accessible to anyone.
In my opinion we should follow some sort of an 'at_console' approach.
We've discussed the start for that in the thread '[resubmit PATCH] Patch
to pretend remote users' [1].

That is precisely what the console.perms stuff does via
pam_console.so. It only makes the device owned by the user if they
are the owner of /dev/console.

It isn't a complete solution to the problem of multiple local console
users though. For that we need to take advantage of ConsoleKit. Take
a look at:
http://people.freedesktop.org/~mccann/doc/ConsoleKit/ConsoleKit.html
http://gitweb.freedesktop.org/?p=ConsoleKit.git;a=summary

Using utmp etc doesn't really work for a variety of reasons. Firstly,
you can't trust the information there since it is writable by many.
Secondly, you don't have a way to distinguish which of the locally
active users should own the device (think about fast user switching).
See the following for some discussion of various issues:
http://live.gnome.org/BetterPowerManager

Post by Timo Hoenig
Once this is in, we can discuss if it is really necessary to make the
device accessible to users.

[Ludwig Nussel]

In summary, I think the solution to being able to use pam thinkfinger
* Set ACL to allow that user to read only their .bir file

If only one user and root need to be able to modify that file you
can just use chown. Since the directory is owned by root and only
writeable by root the user cannot mess with other files. See
/var/spool/mail for example.

* Allow the user that is active on the console/seat to have
permission to write to the thinkfinger device

Once you have access to a device you can keep the fd open even if
permissions change underneath. So if :0 locks the screen and you
switch to :1 you wouldn't be able to authenticate via fingerprint
reader even though :0 no longer has permissions.

cu
Ludwig

[William Jon McCann]

Hi,

Post by Ludwig Nussel

In summary, I think the solution to being able to use pam thinkfinger
* Set ACL to allow that user to read only their .bir file

If only one user and root need to be able to modify that file you
can just use chown. Since the directory is owned by root and only
writeable by root the user cannot mess with other files. See
/var/spool/mail for example.

Well, there are some important differences between these two cases.
User writeable files are allowed in /var but not in /etc. And you
don't want to put login records in /var. A user being able to erase
their own mail is one thing but to (even accidentally) erase their
authentication record is another. Also you probably don't want the
PAM module to read and operate on untrusted data.

Post by Ludwig Nussel

* Allow the user that is active on the console/seat to have
permission to write to the thinkfinger device

Once you have access to a device you can keep the fd open even if
permissions change underneath. So if :0 locks the screen and you
switch to :1 you wouldn't be able to authenticate via fingerprint
reader even though :0 no longer has permissions.

Revoke is in the works from what I understand. But still this
argument is a little silly if at the moment the user on :0 can't even
unlock their screen using the device.

Thanks,
Jon

[Ludwig Nussel]

Post by William Jon McCann

Post by Ludwig Nussel

In summary, I think the solution to being able to use pam thinkfinger
* Set ACL to allow that user to read only their .bir file

If only one user and root need to be able to modify that file you
can just use chown. Since the directory is owned by root and only
writeable by root the user cannot mess with other files. See
/var/spool/mail for example.

Well, there are some important differences between these two cases.
User writeable files are allowed in /var but not in /etc. And you
don't want to put login records in /var. A user being able to erase
their own mail is one thing but to (even accidentally) erase their
authentication record is another. Also you probably don't want the
PAM module to read and operate on untrusted data.

You are right, I missed the point that you only add an ACL to allow
read access.

Post by William Jon McCann

Post by Ludwig Nussel

* Allow the user that is active on the console/seat to have
permission to write to the thinkfinger device

Once you have access to a device you can keep the fd open even if
permissions change underneath. So if :0 locks the screen and you
switch to :1 you wouldn't be able to authenticate via fingerprint
reader even though :0 no longer has permissions.

Revoke is in the works from what I understand.

pam_thinkfinger would probaly get IO errors when the device got
revoked. I wonder how it should know that it's just a temporary
error until the user switches consoles again then.

Post by William Jon McCann
But still this argument is a little silly if at the moment the
user on :0 can't even unlock their screen using the device.

There are different philosphies wrt pam usage. There is one that
says that all pam functions have to be called with sufficient
privileges. Ie. if pam authentication is supposed to work with all
kinds of possible modules you have to be root. Unfortunately that
makes screensavers rather complex.

cu
Ludwig

[William Jon McCann]

Post by Ludwig Nussel
pam_thinkfinger would probaly get IO errors when the device got
revoked. I wonder how it should know that it's just a temporary
error until the user switches consoles again then.

For a PAM module it is really easy to handle this case for a couple of reasons:
* modules generally don't maintain a lot of state
* the lifetime is very short

In the nominal case it only tries to open the USB device in PAM
authenticate and the device is always closed before the function
returns. So a revoke or any kind of error really just causes the
function to return an error and the PAM stack continues. This similar
to the case where the USB device is pulled out (my scanner is external
BTW), or the device can't be found.

In every case that I know of the calling program will just restart the
PAM stack and try again.

Jon

[José Plans]

Post by Ludwig Nussel

In summary, I think the solution to being able to use pam thinkfinger
* Set ACL to allow that user to read only their .bir file

Sounds interesting!

Post by Ludwig Nussel
If only one user and root need to be able to modify that file you
can just use chown. Since the directory is owned by root and only
writeable by root the user cannot mess with other files. See
/var/spool/mail for example.

Sure, chown is the right way. I was thinking the idea from William
doesn't sound that bad, instead of using ACLs I would just get the
chance to the sysadmin whilst recording the .bir record to pass an
option to chown() it; that is just a couple of lines.

I can see why a sysadmin would like that.

Kind regards,

Jose