I got a new corporate VPN tool the other day. It's called Pulse Secure. It worked fine, thank you very much, no complains there. But then I tried to quit
and I got this
That pissed me off right then and there. Why would any remote admin tell me what to do on my local machine? Even if it's a company machine. When I do not use the VPN or maybe I'm not even connected to any WiFi, why should I have this running? It's just silly to try to prevent me from doing something on the machine where I have the root access. When this gets pushed onto a developer's laptop (as opposed to an accountant or an HR clerk) it simply becomes a challenge.
It has no impact on the security of the machine or the corporate network when it's simply running in the background. This is not anti-virus software. It has an impact on the battery life and other resources like RAM and CPU though. And I need those. It's exactly this type of programs that don't exit, hang around and prevent me from running yet another Electron app on my laptop. Sometimes one is not enough, you know.
I guess I'd have to get my hands dirty instead of doing something I was actually going to do. Simply killing it from the command line didn't work. It just starts over. Investigation it is, then.
First, I took a quick look at the list of the open files from the Activity Monitor. There I found a log file (bottom row):
The tool developers were very kind and dumped about half a meg of stuff on every restart cycle into the log. So it's wasting my disk space as well then. Amongst thousands of lines, I found a reference to /Library/Application Support/Pulse Secure/Pulse/connstore.dat. It sounded promising. After poking around in that file and trying this and that, I found a parameter that is responsible for that.
ive "921sn438-qoo8-4pp4-85p7-68q5s2592o32" {
...
connection-policy-override: "false"
...
}
When this parameter is changed to true and the tool is restarted I was able to quit. Voilà!
Yes, I do.
And here the script that automates the whole thing:
cd '/Library/Application Support/Pulse Secure/Pulse'
sudo sed -i '' \
s'/connection-policy-override: "false"/connection-policy-override: "true"/' \
connstore.dat
sudo killall PulseTray 'Pulse Secure' dsAccessService
Dear developers and sysadmins, please don't do that again. You're just wasting everybody's time. Rather put your efforts into making the software more reliable, less resource hungry, more secure.
Originally published on detunized.net
Top comments (9)
I've had similar experiences with poorly chosen or poorly managed 'security' software, and I too have spent a little effort working around those poor choices, partly because it's satisfying but mostly because it helped a team or three be productive when the specific product was invasive and interfered with their day jobs. However - and this is the important bit for me - I didn't stop there with two fingers pointed at the infosec team, because I'm on that team too (it's called the company I work with!). I took the productivity issues to my colleagues whose job is to protect the rest of us from ourselves and too much hasty clicking through warnings.. and challenged all of us to find a better way to meet our security requirements.
In one specific example: a duty of care regulation requires the company to make efforts to protect employees from accessing harmful material on the 'net during their use of company equipment. The infosec team chose (poorly) to deploy Websense, which is a client-side proxy-based filtering product that diverts some http requests through the Websense filters. Unfortunately it only partly protects the end user, depending on which software honours the proxy settings, but does destroy anyone's ability to use Fiddler or other proxy-based network debugging tools - cue large drop in productivity from dev/QA/ops teams. Once challenged to find a better way, and with input from other team members who have worked for other organisations that have already been round this loop, we looked again at the requirements, and decided that we could use network-based transparent filtering to cover the majority of users on corporate networks without any client-side software products, then apply VPN tunnelling and managed default routes for remote workers / road warriors so their 'net traffic is filtered by default. This means our users can disable the protection if they wish, but it has to be a deliberate, knowing action, thus they are taking ownership of the risk, and the company is not at fault should something then go wrong.
I wish my company would agree on this, but they will never.
We also have Websense and we all HATE it. It caused lots of serious trouble to all the developers in my company (lately they force-installed a google chrome extension for it, but I figured out how to delete it :D).
Yep, Websense is not popular. FWIW my workaround was ridiculously easy as Websense relies on a hostname lookup to find it's PAC file.. so I resolve that in my hosts file to 127.0.0.1 then provide my own PAC. It took me 10mins to find and implement this, it would similarly allow a malware author to bypass it's protection, giving me a strong argument for not using client-side security controls, and encouraging the infosec team to look at other options.
Thanks for your reply. I'm going to talk to the admins about this. TBH I don't expect a quick resolution here. Our company is quite large and these things take a while usually.
Thx a lot ! I m feeling less alone !
I will bring your story to my sysadmin
I hope it works. From my experience, though, sysadmins are pretty stubborn people. Wish you luck. Or you could just patch the config file.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.