First off, it's either this applet or another one that doesn't immediately detect the correct range. It can take a significant amount of time for the lock limit to be reached when the proximity isn't set very high.
This can give an attacker just enough time to get on the system and do a few malicious actions, or worse would be the following.
The second thing an attacker could do using either the gap of the maximum proximity or the afore mentioned is kill blueproximity. If an attacker just right clicks the applet and clicks quit or opens a terminal and uses kill (god forbid kill -9) they will not need to worry about what the maximum proximity is.
The best way I can think of to overcome this is have a blueproximity daemon. Once the daemon detects the blueproximity applet is killed, then the lock command is executed. Remembering that the daemon will run as root only and the user and blueproximity will not interact with this device other than when the daemon requests something.
This opens up another security concern. If this occurs then an attacker could quickly change the lock command. No only that, but they could change the proximity limit to the maximum. This will make the system stay unlocked until the device is completely out of range which takes a good distance to do. Yes - this can be done with changing MAC or
A simple resolve here would be to force any setting change to only become effective after a restart of the application. This could even be performed by a right click option. The point here being that it causes the application to detach and the system to lock. This will force the user to acknowledge any changes with minimal interruption.
So...
Make the proximity detection more responsive
Force setting changes to only become effective after application restart
right click option for this
Run a daemon that detects detachment
Make all reboot signal a detach
Use last used setting for lock on detachment
Don't take any of this personally. I think this is an excellent application. I see that this could be extremely reliable at some point. Unfortunately, because of the items mentioned in this bug report, I don't see it as a secure setup.
Launchpad Link: https://bugs.launchpad.net/ubuntu/+source/blueproximity/+bug/286820
I found a couple ways to bypass blueproximity.
First off, it's either this applet or another one that doesn't immediately detect the correct range. It can take a significant amount of time for the lock limit to be reached when the proximity isn't set very high.
This can give an attacker just enough time to get on the system and do a few malicious actions, or worse would be the following.
The second thing an attacker could do using either the gap of the maximum proximity or the afore mentioned is kill blueproximity. If an attacker just right clicks the applet and clicks quit or opens a terminal and uses kill (god forbid kill -9) they will not need to worry about what the maximum proximity is.
The best way I can think of to overcome this is have a blueproximity daemon. Once the daemon detects the blueproximity applet is killed, then the lock command is executed. Remembering that the daemon will run as root only and the user and blueproximity will not interact with this device other than when the daemon requests something.
This opens up another security concern. If this occurs then an attacker could quickly change the lock command. No only that, but they could change the proximity limit to the maximum. This will make the system stay unlocked until the device is completely out of range which takes a good distance to do. Yes - this can be done with changing MAC or
A simple resolve here would be to force any setting change to only become effective after a restart of the application. This could even be performed by a right click option. The point here being that it causes the application to detach and the system to lock. This will force the user to acknowledge any changes with minimal interruption.
So...
Don't take any of this personally. I think this is an excellent application. I see that this could be extremely reliable at some point. Unfortunately, because of the items mentioned in this bug report, I don't see it as a secure setup.