libpam_blue requires root, fails if non-privileged

Bug #912695 reported by Ross Boswell
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
libpam-blue (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

I modified /etc/pam.d/common-auth to allow two-factor authentication using password and either bluetooth proximity or, if that fails, google-authenticator:

. . .
# here are the per-package modules (the "Primary" block)
auth [success=1 default=ignore] pam_unix.so nullok_secure
# here's the fallback if no module succeeds
auth requisite pam_deny.so
#
auth [success=1 default=ignore] pam_blue.so
auth required pam_google_authenticator.so
#
# prime the stack . . .

This works fine for login, but bluetooth authentication always fails when unlocking gnome-screensaver with the error message:
Bluetooth scan failure [bluetooth device up?]

The reason seems to be that pam_blue is based on l2cap which requires root authority to create sockets (l2ping runs as root but fails for a non-privileged user).

An alternative method of detecting bluetooth proximity is to use hcitool:
hcitool name xx:xx:xx:xx:xx:xx
returns the name of the device whose MAC is given, or nothing on fail, and it works for a non-privileged user.

Replacing pam_blue with a simple hacked version using hcitool works for both login and gnome-screensaver unlock:

  int rc = PAM_SESSION_ERR;
  FILE *fpipe;
  char *command="hcitool name xx:xx:xx:xx:xx:xx";
  char line[256];

  if ( !(fpipe = (FILE*)popen(command,"r")) ) {
     perror("Problems with pipe");
     exit(1);
  }
  while ( fgets( line, sizeof line, fpipe)) {
    if (strlen(line) > 2) rc = PAM_SUCCESS;
  }
  pclose(fpipe);
  return rc;

This bug probably affects all versions to date, but has been confirmed in Ubuntu 11.04 and 11.10, and in libpam-blue 0.9.0-3

Tags: patch
Revision history for this message
Ross Boswell (drb-x) wrote :

Patching bluescan.c to follow hcitool rather than l2ping seems to work for both login and gnome-screensaver.
The disadvantage that I can see is that there is no way to change the timeout.

The patch is attached.

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "Patch bluescan.c to use hci_read_remote_name" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags: added: patch
Revision history for this message
Ross Boswell (drb-x) wrote :

OK, so this version of the patch to bluescan.c is fixed to handle error conditions gracefully { return(false) instead of exit(1) } and to report errors using syslog()

Another strange point that I don't understand -- pam_blue, as compiled from the source package, expects its configuration files in
  /etc/security/bluescan.conf
but the Ubuntu distribution expects
  /etc/security/bluesscan.conf [note the extra "s"]

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in libpam-blue (Ubuntu):
status: New → Confirmed
Revision history for this message
Craig McQueen (cmcqueen1975) wrote :

Is pam_blue maintained? It's looking a bit dead at the moment. How can we contribute patches "upstream" or to continue development in Debian/Ubuntu? According to the Ubuntu package, the web site is http://pam.0xdef.net/ but that is not responding, at least not at the moment.

Would it be possible to patch l2ping to work if a non-root user is a member of e.g. "bluetooth" group? From strace, it seems the problem is with a call to "socket(PF_BLUETOOTH, SOCK_RAW, 0)", and raw sockets normally need root user or capability CAP_NET_RAW.

Revision history for this message
Ross Boswell (drb-x) wrote : Re: [Bug 912695] Re: libpam_blue requires root, fails if non-privileged

Dear Craig

As you'll see from the bug report, I found it easier to replace l2ping with hcitool. That worked for me, and I moved on.

Kind regards -- Ross

On 4/06/2013, at 11:36, Craig McQueen <email address hidden> wrote:

> Is pam_blue maintained? It's looking a bit dead at the moment. How can
> we contribute patches "upstream" or to continue development in
> Debian/Ubuntu? According to the Ubuntu package, the web site is
> http://pam.0xdef.net/ but that is not responding, at least not at the
> moment.
>
> Would it be possible to patch l2ping to work if a non-root user is a
> member of e.g. "bluetooth" group? From strace, it seems the problem is
> with a call to "socket(PF_BLUETOOTH, SOCK_RAW, 0)", and raw sockets
> normally need root user or capability CAP_NET_RAW.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/912695
>
> Title:
> libpam_blue requires root, fails if non-privileged
>
> Status in “libpam-blue” package in Ubuntu:
> Confirmed
>
> Bug description:
> I modified /etc/pam.d/common-auth to allow two-factor authentication
> using password and either bluetooth proximity or, if that fails,
> google-authenticator:
>
> . . .
> # here are the per-package modules (the "Primary" block)
> auth [success=1 default=ignore] pam_unix.so nullok_secure
> # here's the fallback if no module succeeds
> auth requisite pam_deny.so
> #
> auth [success=1 default=ignore] pam_blue.so
> auth required pam_google_authenticator.so
> #
> # prime the stack . . .
>
> This works fine for login, but bluetooth authentication always fails when unlocking gnome-screensaver with the error message:
> Bluetooth scan failure [bluetooth device up?]
>
> The reason seems to be that pam_blue is based on l2cap which requires
> root authority to create sockets (l2ping runs as root but fails for a
> non-privileged user).
>
> An alternative method of detecting bluetooth proximity is to use hcitool:
> hcitool name xx:xx:xx:xx:xx:xx
> returns the name of the device whose MAC is given, or nothing on fail, and it works for a non-privileged user.
>
> Replacing pam_blue with a simple hacked version using hcitool works for both login and gnome-screensaver unlock:
>
> int rc = PAM_SESSION_ERR;
> FILE *fpipe;
> char *command="hcitool name xx:xx:xx:xx:xx:xx";
> char line[256];
>
> if ( !(fpipe = (FILE*)popen(command,"r")) ) {
> perror("Problems with pipe");
> exit(1);
> }
> while ( fgets( line, sizeof line, fpipe)) {
> if (strlen(line) > 2) rc = PAM_SUCCESS;
> }
> pclose(fpipe);
> return rc;
>
> This bug probably affects all versions to date, but has been confirmed
> in Ubuntu 11.04 and 11.10, and in libpam-blue 0.9.0-3
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/libpam-blue/+bug/912695/+subscriptions

Revision history for this message
Craig McQueen (cmcqueen1975) wrote :

I've tried that patch, and it does seem to work. Great!

However, it doesn't seem to work for the unlocking the lock screen (Unity GUI, Ubuntu 13.04). I have to type in a password to unlock it. I've seen bug reports about LDAP and the lock screen. But a fingerprint reader PAM (pam_fingerprint-gui) does seem to work on the lock screen. Any idea why pam-blue wouldn't work to unlock the lock screen?

Revision history for this message
Ross Boswell (drb-x) wrote :

Dear Craig

No I can't see why it wouldn't work -- it worked for me with gnome-screensaver and Ubuntu 10.
Perhaps you will get a clue from the system logfiles.
You might also try running hcitool as the user running the screensaver and make sure that user has bluetooth access permissions.

Good luck -- Ross

----- Original Message -----

From: "Craig McQueen" <email address hidden>
To: <email address hidden>
Sent: Friday, 7 June, 2013 12:15:39 PM
Subject: [Bug 912695] Re: libpam_blue requires root, fails if non-privileged

I've tried that patch, and it does seem to work. Great!

However, it doesn't seem to work for the unlocking the lock screen
(Unity GUI, Ubuntu 13.04). I have to type in a password to unlock it.
I've seen bug reports about LDAP and the lock screen. But a fingerprint
reader PAM (pam_fingerprint-gui) does seem to work on the lock screen.
Any idea why pam-blue wouldn't work to unlock the lock screen?

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/912695

Title:
libpam_blue requires root, fails if non-privileged

Status in “libpam-blue” package in Ubuntu:
Confirmed

Bug description:
I modified /etc/pam.d/common-auth to allow two-factor authentication
using password and either bluetooth proximity or, if that fails,
google-authenticator:

. . .
# here are the per-package modules (the "Primary" block)
auth [success=1 default=ignore] pam_unix.so nullok_secure
# here's the fallback if no module succeeds
auth requisite pam_deny.so
#
auth [success=1 default=ignore] pam_blue.so
auth required pam_google_authenticator.so
#
# prime the stack . . .

This works fine for login, but bluetooth authentication always fails when unlocking gnome-screensaver with the error message:
Bluetooth scan failure [bluetooth device up?]

The reason seems to be that pam_blue is based on l2cap which requires
root authority to create sockets (l2ping runs as root but fails for a
non-privileged user).

An alternative method of detecting bluetooth proximity is to use hcitool:
hcitool name xx:xx:xx:xx:xx:xx
returns the name of the device whose MAC is given, or nothing on fail, and it works for a non-privileged user.

Replacing pam_blue with a simple hacked version using hcitool works for both login and gnome-screensaver unlock:

int rc = PAM_SESSION_ERR;
FILE *fpipe;
char *command="hcitool name xx:xx:xx:xx:xx:xx";
char line[256];

if ( !(fpipe = (FILE*)popen(command,"r")) ) {
perror("Problems with pipe");
exit(1);
}
while ( fgets( line, sizeof line, fpipe)) {
if (strlen(line) > 2) rc = PAM_SUCCESS;
}
pclose(fpipe);
return rc;

This bug probably affects all versions to date, but has been confirmed
in Ubuntu 11.04 and 11.10, and in libpam-blue 0.9.0-3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libpam-blue/+bug/912695/+subscriptions

Revision history for this message
Craig McQueen (cmcqueen1975) wrote :

I've sorted it out now. Sorry, I was doing something stupid. I had thought "it was working" but I was still actually running the original pam-blue. I thought it was "working" because I had solved a separate issue -- my Bluetooth device had a space in the name, and I couldn't figure out how to configure that in /etc/security/bluescan.conf. I removed the space in the device name on my Bluetooth device (an iPhone), then it worked, but still with the original pam-blue, except for lock screen.

So what I was missing was to compile and install with the proper configure options, so the module goes into /lib/security:

./configure --libdir=/lib/security
make
sudo make install

Revision history for this message
Ross Boswell (drb-x) wrote :

Glad to hear you got there.

Congrats -- Ross

On 7/06/2013, at 13:47, Craig McQueen <email address hidden> wrote:

> I've sorted it out now. Sorry, I was doing something stupid. I had
> thought "it was working" but I was still actually running the original
> pam-blue. I thought it was "working" because I had solved a separate
> issue -- my Bluetooth device had a space in the name, and I couldn't
> figure out how to configure that in /etc/security/bluescan.conf. I
> removed the space in the device name on my Bluetooth device (an iPhone),
> then it worked, but still with the original pam-blue, except for lock
> screen.
>
> So what I was missing was to compile and install with the proper
> configure options, so the module goes into /lib/security:
>
> ./configure --libdir=/lib/security
> make
> sudo make install
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/912695
>
> Title:
> libpam_blue requires root, fails if non-privileged
>
> Status in “libpam-blue” package in Ubuntu:
> Confirmed
>
> Bug description:
> I modified /etc/pam.d/common-auth to allow two-factor authentication
> using password and either bluetooth proximity or, if that fails,
> google-authenticator:
>
> . . .
> # here are the per-package modules (the "Primary" block)
> auth [success=1 default=ignore] pam_unix.so nullok_secure
> # here's the fallback if no module succeeds
> auth requisite pam_deny.so
> #
> auth [success=1 default=ignore] pam_blue.so
> auth required pam_google_authenticator.so
> #
> # prime the stack . . .
>
> This works fine for login, but bluetooth authentication always fails when unlocking gnome-screensaver with the error message:
> Bluetooth scan failure [bluetooth device up?]
>
> The reason seems to be that pam_blue is based on l2cap which requires
> root authority to create sockets (l2ping runs as root but fails for a
> non-privileged user).
>
> An alternative method of detecting bluetooth proximity is to use hcitool:
> hcitool name xx:xx:xx:xx:xx:xx
> returns the name of the device whose MAC is given, or nothing on fail, and it works for a non-privileged user.
>
> Replacing pam_blue with a simple hacked version using hcitool works for both login and gnome-screensaver unlock:
>
> int rc = PAM_SESSION_ERR;
> FILE *fpipe;
> char *command="hcitool name xx:xx:xx:xx:xx:xx";
> char line[256];
>
> if ( !(fpipe = (FILE*)popen(command,"r")) ) {
> perror("Problems with pipe");
> exit(1);
> }
> while ( fgets( line, sizeof line, fpipe)) {
> if (strlen(line) > 2) rc = PAM_SUCCESS;
> }
> pclose(fpipe);
> return rc;
>
> This bug probably affects all versions to date, but has been confirmed
> in Ubuntu 11.04 and 11.10, and in libpam-blue 0.9.0-3
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/libpam-blue/+bug/912695/+subscriptions

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.