Disable Bluetooth File Sharing

[jmb03012]

We are trying to find a way to disable Bluetooth File Sharing and prevent re-activation by clients. I've successfully disabled it several different ways via scripts but the issue is preventing the re-enabling by the clients.

User Level MCX or Configuration Profiles will disable it at login but then the client is able to re-enable it again until they logout or restart; same goes for running the scripts as part of a policy at login. I could run a policy on the every15 but that still leaves security holes and is a less than ideal approach.

The Sharing pane in System Preferences doesn't require Admin rights to access and as far as I can find, there isn't a way to grey out the Bluetooth File Sharing box inside of it.

Any suggestions are appreciated!

[nicktong]

Assume you have contemplated restricting access to the whole Sharing pane itself via MobileConfig? I know its less than ideal; we have had a long standing rdar with Apple to get more granular controls over restrictions. Then there's also the issue that restrictions are a white-list not a blacklist - so when you restrict something, we're really whitelisting the ones we want to allow - which is problematic because of third-party panes, and we don't know the name of all the 3rd party ones, so makes whitelisting a bit difficult. Wish there was an option to have one bucket of Apple pref panes which we would whitelist independently of third-party panes. In this case, the only other option I see is to slap a daemon on the client and have it run your script more frequently.

[jmb03012]

Restricting the whole pane certainly wouldve been the easiest approach but unfortunately its not an option as we need to leave the panel accessible for troubleshooting by our Help Desk and Desktop Support when necessary which is what brought me to trying to restrict just that option.

A dameon is certainly a possibility but as this is a security driven initiative, ideally there would be zero gaps and it would be of all the time, with a daemon, that would be a lot of runs over and over indefinitely =/

[nicktong]

@jmb03012

Was thinking about this a bit more since we have a similar need. Curious what your thoughts are around using JAMF’s built-in Restricted Software facility?

Best I can tell, there are two execs to prohibit:

The Bluetooth File Sharing app:

/Applications/Utilities/Bluetooth File Exchange.app/Contents/MacOS/Bluetooth File Exchange

And the OBEXAgent, which is, I believe, used exclusively for Bluetooth file exchange and nothing else:

/System/Library/CoreServices/OBEXAgent.app/Contents/MacOS/OBEXAgent

Using this we could restrict the bluetooth sharing and optionally display a dialog like this:

external image link

The restrictions themselves would look like this:

external image link

external image link

[jmb03012]

@nicktong

I believe you correct, those are the two items. That had also came up during discussions about restricting the whole Sharing pane but while that wouldve impacted the techs, this could have potential user impact.

By restricting those apps, but still leaving the pane open, it gives the appearance to the client when they toggle BT sharing on/off that it should work but with the apps restricted, its not going to. This ultimately will lead to tickets to the Help Desk about why a service isnt working that on the backend shouldnt be.

A similar idea we had to restricting the apps would be leaving them enabled but created some type of white/black list of what could/could not be paired. However the issue is the same here, clients will think something that we know is working the way we (IT) want it to work isnt working correct.

Its a very simple problem that Apple made very complicated by not putting a locking mechanism on that panel....

[jmb03012]

@nicktong

So an update on this, you can actually lock down the sharing pane by enabling the pref in the Security pane to require an administrator to unlock system preference panes...unfortunately Bluetooth Sharing still remains accessible even when locked.

Tried looking into locking the permissions on that file but it creates consistent crashes. Looks like we may just need to go the route of using Restricted Software in Casper to hunt and kill those processes.

[nwagner]

I know this is an old thread, but ... bump

Anyone have a solid way to do this in Mojave (10.14)?

I have OBEXagent.app restricted, as well as Bluetooth File Exchange.app. I feel like in Mojave and JAMF 10.10 there should be a more elegant solution to this.

Restricting those two apps seems to work, it kicks my Android when I try to connect. Message doesn't pop up though.

[chris_kemp]

That's pretty much what we did at my last job, and it did the trick. We also did not want to restrict general Bluetooth functionality, only file transfers - leveraging Restricted Software worked well enough.

[easyedc]

Just bumping the bump. I have tried setting this up restricting the exact process name, wildcards, the app name, a few ways. But I can still perform the file transfers. Are you guys getting successful blocks both directions? FWIW, I tried blocking a send of a file, which works for me. I can not block receiving files at all.

[CodyC]

I was able to achieve blocking of transfer by only restricting the BFE

/Applications/Utilities/Bluetooth File Exchange.app/Contents/MacOS/Bluetooth File Exchange

Thanks for the suggestions and info.

[WinsNdr1]

Hi CodyC, could you let me know how was the BFE blocked. Was it through Intune or a script or a command.

[MichaelMcG]

Hi, 

I'm also looking at how to block this, can you share how you managed to do it?

[easyedc]

It should be with a Restricted Software entry killing the process name. 

 

[MichaelMcG]

Thanks, figured it out right after i posted, thanks for replying though!

[dacontracta]

This worked for me too! Just in case the image goes down, the solution is just to enter "Bluetooth File Exchange.app" (no quotes, no need to escape the space) in the Jamf > Computers > Restricted Software > (pick or make a policy) > Process Name field. Also check the "Kill process" box. They have "Restrict exact process name" checked in the photo, but mine also works without that box checked. Either's fine, I guess.

[dacontracta]

Beware this train of thought! It would seem as if you could do this natively in Jamf Pro by going to Computers > Configuration Profiles > Restrictions > Applications > checking the "Restrict which apps are allowed to launch" checkbox > typing "/System/Applications/Utilities/". And yes, this would prevent users from launching Bluetooth File Sharing. But it also prevents users from launching any application in the Utilities folder, like Print Center and System Information! It does too much.

The real issue is, in Computers > Configuration Profiles > Restrictions > Applications > checking the "Restrict which apps are allowed to launch" checkbox, why does Jamf have a "Allow Apps" list, but not a "Deny Apps" list? C'mon, that seems obvious. Get your act together Jamf.

[dacontracta]

Solution for this, actually: do the first paragraph, but instead type "/System/Applications/Utilities/Bluetooth File Exchange". Apparently .app files count as directories and so this will prevent the launching of Bluetooth File Exchange, but still allow other apps within /System/Applications/Utilities to launch.
Do note, this method causes the following "blocked" message to appear when Bluetooth File Exchange is launched:


while easyedc's method above makes this "blocked" message appear:


Personally, I prefer the second "blocked" message, because the first makes it sound like IT will allow Bluetooth File Sharing if they ask. Which we won't, and I don't want them to email me about it.