Purpose

• currently a deauthentication server is spawned each time the PAM unlocks the desktop
• investigate whether it would be a good idea to have the authentication server start at start-up and instead of killing itself, it just disconnects the device and lock
  • when PAM unlocks, send a message to deauthentication server (i.e. IPC or some lightweight messaging protocol) to know which Bluetooth address to expect
  • would need a way to ensure authentication server is running after unlock (could be as simple as a bash program to see if a process is running after 2 seconds from logging into the system)

Tasks/Goals

• Break the issue into smaller tasks how you will approach the problem

Summary

To fill out once the issue is to be closed. Give a short summary of the changes you made to implement or fix an issue

Purpose

Display device information from the Bluetooth manager. #51 deals with the frontend but this task deals with the backend

Tasks/Goals

• Send data to the new activity/fragment
• Use data binding rather than findviewbyid (refer to this page)
• Toggle is set to ON automatically once Bluetooth connection is established
• Toggle OFF will exit the fragment/activity and goes back to the default device

Summary

To fill out once the issue is to be closed. Give a short summary of the changes you made to implement or fix an issue

There are a lot of memory leaks in the rfcomm-server. The starter code I have gotten from the internet has issues with memory leaks. This is an issue because there is memory usage that may not be needed for the entire duration of the program and so eats up unnecessary memory.

=================================================================
==22661==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 32 byte(s) in 2 object(s) allocated from:
    #0 0x7fece2e49ae8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dae8)
    #1 0x7fece2d27464 in sdp_list_insert_sorted (/lib/x86_64-linux-gnu/libbluetooth.so.3+0xf464)

Direct leak of 32 byte(s) in 1 object(s) allocated from:
    #0 0x7fece2e49ce6 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dce6)
    #1 0x7fece2d2a28a in sdp_create (/lib/x86_64-linux-gnu/libbluetooth.so.3+0x1228a)

Direct leak of 16 byte(s) in 1 object(s) allocated from:
    #0 0x7fece2e49ae8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dae8)
    #1 0x7fece2d27359 in sdp_list_append (/lib/x86_64-linux-gnu/libbluetooth.so.3+0xf359)

Indirect leak of 912 byte(s) in 19 object(s) allocated from:
    #0 0x7fece2e49ce6 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dce6)
    #1 0x7fece2d27ee6 in sdp_data_alloc_with_length (/lib/x86_64-linux-gnu/libbluetooth.so.3+0xfee6)

Indirect leak of 176 byte(s) in 11 object(s) allocated from:
    #0 0x7fece2e49ae8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dae8)
    #1 0x7fece2d27464 in sdp_list_insert_sorted (/lib/x86_64-linux-gnu/libbluetooth.so.3+0xf464)

Indirect leak of 60 byte(s) in 3 object(s) allocated from:
    #0 0x7fece2e49ae8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dae8)
    #1 0x7fece2d289f7 in sdp_uuid_to_uuid128 (/lib/x86_64-linux-gnu/libbluetooth.so.3+0x109f7)

Indirect leak of 58 byte(s) in 3 object(s) allocated from:
    #0 0x7fece2e49ae8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dae8)
    #1 0x7fece2d27f33 in sdp_data_alloc_with_length (/lib/x86_64-linux-gnu/libbluetooth.so.3+0xff33)

Indirect leak of 48 byte(s) in 1 object(s) allocated from:
    #0 0x7fece2e49ce6 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dce6)
    #1 0x7fece2d2a2a6 in sdp_create (/lib/x86_64-linux-gnu/libbluetooth.so.3+0x122a6)

Indirect leak of 20 byte(s) in 1 object(s) allocated from:
    #0 0x7fece2e49ae8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dae8)
    #1 0x7fece2d289f7 in sdp_uuid_to_uuid128 (/lib/x86_64-linux-gnu/libbluetooth.so.3+0x109f7)
    #2 0x80000080000fffff  (<unknown module>)

Indirect leak of 16 byte(s) in 1 object(s) allocated from:
    #0 0x7fece2e49ae8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dae8)
    #1 0x7fece2d27359 in sdp_list_append (/lib/x86_64-linux-gnu/libbluetooth.so.3+0xf359)

SUMMARY: AddressSanitizer: 1370 byte(s) leaked in 43 allocation(s).

Purpose

There are a few different projects similar to this one and are stable. It would be interesting to take a look at what they are doing and compare our approaches to see what is the best way to approach this problem

Tasks/Goals

• Bluetooth-Unlock
• BLE-Unlock

Summary

To fill out once the issue is to be closed. Give a short summary of the changes you made to implement or fix an issue

For fun, it may be worthwhile to write a Rust port. Rust is a safe language that can mitigate careless security vulnerabilities in the C code. Though I don't imagine this issue will be looked at till many other issues are resolved such as rewriting the Android application and the Fedora Port is completed.

I have been thinking of adding a license to this project since the early stages of this project but I never thought of what licenses to choose from. I have assigned this issue to all original members of the project since it's a project we all worked on together so I don't want to assign a license that some members in the team disagree on. I will probably choose a license by June 1, so if anyone has suggestions or arguments please express them over here by June 1.

Here are some features I am looking for in a license:

• freedom to allow others to make modifications and distribute the software as they wish
• freedom to view the source code
  • I want others to be able to view the source code to see how the system works and learn from it
  • I also want to see any derivations of the source code if requested so that I can see what improvements have been made

With these following conditions, I do not like popular licenses such as Apache License 2.0 and MIT License because the source code can be hidden if the project is distributed under a bigger project.

The licenses I have been leaning towards are GPLv2 and GPLv3 but I am struggling between the two. GPLv2 does provide everything I want but allows tivoization. Tivoization from what I understand allows hardware manufacturers to lock their system to now allow different signatures of the software to be installed onto their system. I recall how I disliked the move Sony did with their Playstation 3 where the lockdown their system later on to remove the option to boot Linux. As a kid, I was also frustrated with the fact that Apple locked down their system to make installing other OS in their products. I always wanted the ability to tinker products such as game consoles to modify it the way I want it without being locked down. I am not exactly clear what tivoization exactly is but I have this negative feeling about allowing tivoization. However, I do not think it is the software developer's right to limit any hardware distributor on how open they want their system to be. Hence why I was thinking of GPLv2 and not GPLv3 (which can prohibit tivoization).

In addition, if anyone wants to improve our project (I feel that it's incomplete and should be worked on), feel free to make modifications to the project. I just ask that you create an issue and create a pull request. You can merge your changes to master if you wish to but please add me as a reviewer. This way I know what modifications each member is trying to make and why they are trying to make some modifications. I will try to do the same.

tldr: Kill deauth program when the user locks their computer manually.

tldr Approach: Listen to the changes in state of status in session dbus the interface: org.gnome.SessionManager.Presence

Currently, deauth can only be terminated via three ways:

1. Kill the process
2. Failed to Authenticate (In our current implementation, it's just failure to respond on time)
3. Log off the machine which effectively kills all processes in the session

Issue:
An issue can arise where a user logs in via proxy_auth PAM. A deauth program will be executed but what if the user chooses to manually lock their system? There will be multiple instances of deauth that can be created. The reason why the deauth program may not be killed is because the user simply locked their computer to take a "break" and be within the vicinity of the system and therefore still able to respond to the challenge and response of the system. However, when they wish to log back into their session, the user just needs to be in the login screen (not the general lock screen) which will spawn another deauth. This can cause a conflict because there'll be two bluetooth servers advertising the same uuid which is a big issue. From what I observed, it causes an infinite loop where one server connects to the laptop itself somehow. Not sure how this occurs exactly but I do know it's an issue.

Potential Solution:
Looking into various documentations, source code from various desktop environment vendors including GNOME and PopOS, and StackOverFlow, I think the best approach is to check the value of status from org.gnome.SessionManager.Presence

According to the documentation:

<property name="status" type="u" access="readwrite">
      <doc:doc>
        <doc:description>
          <doc:para>
            The status of the session.
          </doc:para>
          <doc:para>
            The status parameter must be one of the following:
            <doc:list>
              <doc:item>
                <doc:term>0</doc:term>
                <doc:definition>Available</doc:definition>
              </doc:item>
...
              <doc:item>
                <doc:term>3</doc:term>
                <doc:definition>Idle</doc:definition>

We can just listen to changes on the property status if it ever becomes a 3. We will be monitoring (i.e. adding the change of status property to our watch list).

I see that GNOME has a good example of how to add things to our watch list: https://gitlab.gnome.org/GNOME/glib/-/blob/master/gio/tests/gdbus-example-watch-proxy.c

I recall seeing this a month and a few weeks ago but I thought the watch literally meant a watch but now I am slowly learning more about DBus, I realized I was completely wrong.

As the title states, the death, rfcomm-server, should only communicate with the trusted device that logged PAM. This issue is not addressing whether or not the device is what they claim to be. We are just checking if the incoming connection is from the device we want to connect with.

After logging into the system, we want to run a program that will allow us to continually challenge the hardware authentication device (the android app) to confirm its identity. How challenge response works is a separate issue. The focus is simply to run the rfcomm-server once authenticated.

IDEAS:
Idea 1: Have PAM fork a process that executes the rfcomm-server
* When lockout occurs, we can simply have the rfcomm-server to exit after locking the user

Idea 2: Call a script in the Postlogin script or Presession script of GDM which gets called after the user has successfully authenticated GDM. Postlogin gets called before pam_open_session call and Presession is created after the user session has been initialized. To terminate the program, we could have the PostSession script of GDM to kill the process that deauth user.

Idea 3: Research into DBUS more and observe what calls are made when a user gets authenticated and locked out to create a hook that will fork and kill the forked process.

I am leaning towards Idea 1 simply because it seems to be the most simplest approach and uses less of GDM's implementation. Reason is that if we want to expand this to not be a distro or display manager dependent, we should avoid using implementation that are less cross platform and less cross display manager dependent. Current implementation does require use of GDBus which is GNOME dependent. We can simply not use GDBUS in future implementation or have a macro that only uses GDBUS if we are using GNOME and some other DBUS library for other distros and display manager.

Problem: The current implementation requires bluetooth to work. If there is no bluetooth adapter in your machine or if it's turned off.

-currently opens connection if in paired list
-would fail to make a connection if out of range

how to improve
-try to connect until successful
-or cross-reference with the list of available devices(might be more time consuming)

Purpose

Setup a CI pipeline for Github and Jenkins. The goal is to integrate CI DevOps practice both for the project and for personal learning. This is to include code coverage, static analysis, and lint. May setup a zenhub board to better manage issues and explore other devOps tools offered on Github and Jenkins to improve workflow.

Tasks/Goals

• Ensure Github Actions can Build Ubuntu Builds
• Setup Jenkins Server on Raspberry Pi
• Setup Security Code Analysis
• Setup Ubuntu node on Jenkins (perhaps change to Fedora)
• Setup static analyzers
• Setup doxygen workflow generation and deployment
• Setup linter
  • See if splint is a good idea to add to workflow
• Setup fuzzer (i.e. afl)
• (optional) setup cppcheck

Summary

To fill out once the issue is to be closed. Give a short summary of the changes you made to implement or fix an issue

• Github action workflow to build code has been completed
• Github action workflow static analysis has been completed (using CodeQL)
• Github action workflow to generate oxygen and deploy on github pages has been completed

Current implementation of our C bluetooth server is to only read one message from the Android device. The program should be improved to allow read and write with the C bluetooth Server and the Android Application. This issue is only focusing on the C server only. A separate issue should be made for the Android team. Those working on the issue should work with the Android development team.

The file that contains the user's trusted devices should not be trusted. In security, it is good practice to sanitize inputs (the file) when processing the program.

I am thinking of an option to sanitize the file when PAM processes the file. This issue will cover two things:

1. Ignore invalid inputs when reading (i.e. don't try to process invalid lines)
2. Add option to have PAM remove all invalid inputs

SInce I use Fedora as my main OS, I need to get Proxy Auth to work for development purposes. A struggle I'm having is getting Android Studio work with the code :/

@kay911kay committed a80b27f2be1aeb4c267acec727da639e9e580326 which resolves the issue.

When the server closes the socket or terminates, the application should know that the program has been terminated and go back to the main page or at least have some indicator (i.e. toast) that the connection has been severed.

Purpose

• Patch yet another security vulnerability
• Program crashes if the string parameters (i.e. char *) is NULL

Tasks/Goals

• Check if string is NULL at the beginning of the function

Summary

To fill out once the issue is to be closed. Give a short summary of the changes you made to implement or fix an issue

Purpose

Replace existing function comments with Doxygen-style comments so that I can generate code documentation.

Tasks/Goals

• Install Doxygen on a personal machine
• Replace a single header file with Doxygen-style comments
• Change all header files to comply with Doxygen-style comments
• Update Makefile to have an option to generate Doxygen
• Create Github Action to generate Documents whenever a header file is updated

Summary

To fill out once the issue is to be closed. Give a short summary of the changes you made to implement or fix an issue

Purpose

Affected Platform: Ubuntu

• make install fails to detect OS so it does not install any dependencies. This is because of the changes introduced to the Makefile and install.pl: dc3d1e9
• Log: https://github.com/zakuArbor/proxyAuth/actions/runs/1801673612

Tasks/Goals

• Find the correct method to determine OS
• Make changes
• Test on both Fedora and Ubuntu

Summary

To fill out once the issue is to be closed. Give a short summary of the changes you made to implement or fix an issue

The goal is to integrate bluetooth to Linux PAM. Essentially we will be hard coding the device's identifier and if PAM detects the device's identifier, it'll log into the machine.

PAM module is vulnerable to link file attack. Although, it'll be hard for the attacker to gain write access to /etc/proxy_auth, it's possible that the administrator to set the permissions loosely or they happen to be able beat a race condition.

The link file attack is where the user's bluetooth whitelist file is a link rather than a regular file to a sensitive file such as /etc/passwd. We want to avoid this by being strict.

• Ensure file is not a link
• Ensure directory is not a link
• Ensure file has the right permission (like ssh where if .ssh/authorized_hosts permission isn't set correctly, it should fail)

Implement a program in C that can receive data from bluetooth

If possible, coordinate with the Android team to test the program. If not, implement a client that sends data via bluetooth to the receiver.

Since Bluetooth Address is in plain text, it would potentially help an attacker know what address to spoof. Encrypting the Bluetooth address on the file and comparing the encrypted BT address stored from the file and the encrypted BT address is much better than comparing the two addresses in plain text. A one way hash is a great idea to work with.

Remove the lag associated with the PAM when entering the password (i.e. when logging into the machine via password, there's a significant delay)

There is no delay when logging on if bluetooth is turned off because there's no bluetooth adapter to scan the devices in the area.

Purpose

• Static Analyzer triggered a buffer overflow warning
• Note: I believe security bugs like these are not supposed to be public but I am not aware of anyone using the project
• A good example of static analyzers catching bugs in the code

Tasks/Goals

• Replace strncpy size parameter with the minimum of either the length of the string or the size of the buffer
• Ensure no writes are done pass the buffer size (i.e. buf[SIZE - 1] instead of buf[SIZE]
• use assert to ensure program does not exceed a certain length

Summary

To fill out once the issue is to be closed. Give a short summary of the changes you made to implement or fix an issue

Store Trusted Bluetooth Device to a file (we are not going to check how a device is trusted, that’s for another sprint)

Furkan has suggested a hardware idea to use Ubertooth One for our project.

Deadline: Tuesday 11:59pm
Goal:

• Read up on bluetooth and investigate what we could do with Ubertooth
• Find a use case for Ubertooth
• Make a decision whether or not to order the device

Device: https://www.amazon.ca/Ubertooth-One-Aluminum-Enclosure-Bundle/dp/B07GBDD53W/

Each member who is interested should write their findings and ideas to this issue. Please stick to one post for all your findings and ideas and edit the post you wrote to add any additional findings you have found. You are free to create more posts if it's to ask questions or comment on someone's findings.

While working on bluetooth server, I notice that the Android application allows me to connect to devices even if the device's bluetooth is not even on nor in proximity.

EDIT: This issue will include conversations on how challenge response works, message protocols and etc.

This issue is more of a discussion rather than an implementation. We want to know what different levels of authentication there should be and how should it look like in high level as well a general idea of how to implement different levels of authentication.

Purpose

• A list of places to clean up code
• Does not add any new functionality nor enhancement
• Just running away from writing my physics labs :(

Tasks/Goals

• Add a guard statement
  • Negate condition and return early to remove one level of nest
• Add an extra * at the beginning of each comment (i.e. /**) so that doxygen can parse in pam_sec.h

Summary

To fill out once the issue is to be closed. Give a short summary of the changes you made to implement or fix an issue

-Store selected device BT info in android memory
-If a device has been previously been set up, do not prompt the user to select a device and attempt a BT connection instead

Reading through a few papers, articles, and forums I came to the conclusion that the standard Bluetooth chip isn't suffice to approximate distance. The apple airtag seems quite interesting in how relatively accurate it is but I believe you need a special bluetooth chip that exists in Apple's hardware and therefore not valid to our problem.

Our current implemenation is very poor and hardcoded to specific events and is extremely inaccurate.

Goal: To autolock if the device is too far from the laptop. We'll not aim for a specific range but instead classify the ranges as near or far. Near means the device is within the threshold we callibrated by taking account of the RSSI from various points within and outside the acceptable ranges. We'll add profiles whereby the user can select the threshold depending on where they are (i.e. at home or at the office where there are lots of noises).

Proposed Solution

Ever since the covid-19 outbreak, there has been a surgence of interest in bluetooth distance approximation. While I am not knowledgeable in how Google and Apple are able to figure out an estimate whether or not two devices are relatively close to each other (i.e. possible exposures which could mean 2 meters or perhaps a bit more), I think it's good enough for our usecase. Being able to estimate if a user is outside even a distance of 5m is better than nothing.

However, there are some details I'll need to look into but there's a paper I quite like titled Distance Estimation and Positioning Based on Bluetooth Low Energy Technology where by they use fingerprinting to improve approximating the distance between two devices. It's suitable for indoor environments (i.e. a room) and the main idea (from a very quick glance) is that you measure the strength of the device on many points in the room to determine the location. The room is "fingerprinted" by creating a "fingerprint" 1 meter for each other.

Summary

Method 1:

• Use fingerprinting but with less points
• Use RSSI to measure strength instead of bandwidth
• Use OTP to determine if the devices are who they claim to be
  • Alternate every few tries, one device hashes their OTP and the other receives it and hashes the OTP it expects

1. Have the device be on the edge of the laptop and measure the RSSI
2. If measured RSSI decreases by 25%, close the connection
3. Use OTP to verify the device authenticity in case of a connection hijack or impersonnation
4. Allow callibrations (i.e. fingerprinting)

• Measure RSSI when the phone is on the laptop
• Measure the RSSI 1m away from the laptop
• Measure the RSSI 2m away from the laptop or at some point within the acceptble range (the acceptable range has to be a bit large such as 4m because what we are strivin
• Measure the RSSI outside the acceptable range from the laptop
• We create an average what is acceptable and what isn't

Method 2: Use GAEN API

• since GAEN API anonymize device by giving it a random id that constantly changes, we'll need the devices to share its new id each time

Epic: As a user, I want a functioning and easily installable Android application to authenticate my device

Goal: Rewrite the entire Android Application (I also gain full ownership of the Android component of the project)

App Flow

• when the user opens the app, they'll be shown a list of previously connected devices
• when a user selects a device, they will automatically try to connect and authenticate
• each item in the list will have a gearbox where they can edit and see device information

Make sure the Android app is able to receive messages from the C server application

I am experiencing an issue where pairing with a mobile device succeeds, however the device is immediately disconnected. Additionally, odd hiccups where pairing does not prompt passcode.

Any fix or help will be appreciated.

I cannot install the app onto my phone and setup android studio. A lot of things are deprecated. It's probably more productive to rewrite the code and also review how Kotlin works

Unfortunately, the new app will target Android 9 which will target 39.5% of Android devices. There needs to be a balance between acessibility and security. I could have chosen Android 8.1 but I wanted to choose a version of Android that will be supported by the time I make sufficient progress (which I estimate to be December 2021 because I'll be busy with school).

Purpose

Improve debugging by adding assert statements to limit the number of undefined behavior.

Also make more use of const on pointers and variables in function parameters

Tasks/Goals

• ensure username string length is not over the Linux defined length
• ensure length of file path does not exceed defined max length on Linux
• and more to be included ...

Summary

To fill out once the issue is to be closed. Give a short summary of the changes you made to implement or fix an issue

Epic: #50
Description: When the user selects the device, they'll be redirected to either a fragment or an activity where they'll have the device overview where they can:

• see the name of the device
• the address of the device
• Is it currently authenticating a device
• revoke trust
• Start/Stop authenticating a device

Tasks

• When a device is selected, a new activity/fragment
• The new activity/fragment will contain placeholder values (i.e. display name, address, is the device being authenticated, and a toggle)
• Have the toggle button change color depending on if the connection is on or off

Note: This activity/fragment in future iterations will not be the default behavior when they select the device. The end goal is to have this activity/fragment only appear when the user selects a gearbox (i.e. settings) similar to how it is on the Android Bluetooth.

Summary:

• 6bd30ce already completes the UI to view the device information (with non-real values). #58 deals with the backend.

When executing deauth from PAM, it gets executed as root and not the user. There are a few problems with this. The most obvious issue is that the dbus command to lock the screen can only work if the one issuing the command has GNOME Desktop GUI running. If deauth as root executes a lock command, there's no GUI Desktop environment to lock.

The current implementation requires the server to respond before it can read another input from the client (Android device). We should improve the server to allow the server to read and write messages without any blocking.

Related Issue: #14

Investigate whether vfork should be used instead of fork. I saw a video where a developer used vfork instead of fork and seems like a better choice. Will need to read up on the subject before making code change.

The current implementation requires the user to manually connect with the deauth program. Although fine in early stages, we want to ensure smooth usage that is secure as well. The server implementation will not wait for a connection in the near future implementation and will just simply lock the computer for security purposes.

Purpose

• Bound checking when looping over arrays
• • Bound checking when using strncpy
• use of unsigned variables to ensure numbers are not negative
• More usage of macros defined in limit.h

Tasks/Goals

• pam_bt_trust.c:
  • find_trusted_paired_devices:
    • use of unsigned for number of paired devices
    • ensure it's not over BT_MAX_CONN
  • get_trusted_dev_file:
    • increase filename size to use PATH_MAX and use LOGIN_NAME_MAX (will be assuming it's smaller than NAME_MAX which it is on Linux) to check length of username
    • bound check when strcpy that username and trusted_dir_path is not over the limit
  • set_trusted_devices:
    • use unsigned int for number of trusted devices
    • ensure number of trusted devices is limited to max of BT_MAX_CONN

Summary

To fill out once the issue is to be closed. Give a short summary of the changes you made to implement or fix an issue

When the system locks, the app does not indicate the connection has been lost. The app should go back to the main application screen when the lockout occurs.

I am finding an unstable behavior with deauth. Sometimes I would be immediately locked from the laptop right after connecting to the Bluetooth server.

The issue is with the fact that we compare between stop and start but only start is initialized with a value after the connection occurs while stop has no value. In C, not initializing a variable would mean the variable has a random value. It comes to a shock how this was not an issue during our presentation.

If I wish to log into the machine without using bluetooth, the login process takes a few seconds because it is scanning for the device.

We need to think of how to allow signing in with password not be interfered by the bluetooth scanning.

I have noticed that no one has worked on writing the log for sprint 2. The Android team, please update what are the next sprint goals. Each member should also have updated the log to write what they did as well.

Goal:

• Send a message such as "Hello World" to the desktop via Bluetooth from the App

You can talk to those working on #3 to test your application.