Posted on 06-04-2014 01:13 PM
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!
Posted on 06-04-2014 01:29 PM
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.
Posted on 06-04-2014 01:33 PM
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 =/
Posted on 06-04-2014 03:57 PM
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:
The restrictions themselves would look like this:
Posted on 06-05-2014 09:30 AM
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....
Posted on 06-09-2014 08:06 AM
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.
Posted on 02-19-2019 12:40 PM
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.
Posted on 02-19-2019 06:08 PM
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.
Posted on 06-14-2019 12:26 PM
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.
Posted on 07-14-2022 08:58 AM
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.
Posted on 09-13-2022 06:21 AM
Hi CodyC, could you let me know how was the BFE blocked. Was it through Intune or a script or a command.
Posted on 02-27-2024 04:56 AM
Hi,
I'm also looking at how to block this, can you share how you managed to do it?
Posted on 02-27-2024 05:44 AM
It should be with a Restricted Software entry killing the process name.
Posted on 02-27-2024 05:46 AM
Thanks, figured it out right after i posted, thanks for replying though!