libpam_blue requires root, fails if non-privileged

[Ross Boswell]

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

[Ross Boswell (drb-x)]

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.

[Ubuntu Foundations Team Bug Bot (crichton)]

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

[Ross Boswell (drb-x)]

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"]

[Launchpad Janitor (janitor)]

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

[Craig McQueen (cmcqueen1975)]

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.

[Ross Boswell (drb-x)]

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

[Craig McQueen (cmcqueen1975)]

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?

[Ross Boswell (drb-x)]

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

[Craig McQueen (cmcqueen1975)]

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

[Ross Boswell (drb-x)]

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