https://github.com/osquery/osquery logo
Join Slack
Powered by
has anybody come up with a workaround for the `scr...
# general
c
has anybody come up with a workaround for the 
screenlock
table being busted in the newish mac osx releases?
s
What’s broken about it?
c
s
That blog post has a callout at the top:
Screenlock status can once again be monitored. Please see the following updated article for details on how we reverse engineered a solution and how you can check the state of your devices screenlock settings.
https://www.kolide.com/blog/how-kolide-built-its-macos-screenlock-check
c
yes its a kolide-specific table
s
Only sorta? The 
screenlock
table uses an undocumented API, and it needs to run as the user you’re looking for. So you need some kind of sudo like functionality. That’s what the kolide table does.
It changes to user permissions, re-invokes osquery, and uses the 
screenlock
table
c
screenlock is broken, kolide wrote their own extension to implement 
kolide_screenlock
. i was asking if there was a an upstream osquery solution to this issue to a table they support
s
That is not a good summary of what happened. no.
c
screenlock
already had the user limitation and was acceptable, the issue is that mac os x moved the actual setting out of a plist where screenlock is expecting it to be
s
No. that’s not even a little correct.
The old screenlock table used a plist, and needed the user specified. (If I recall correctly, it was reading a plist from the users homedir) Apple removed that plist Years passed with no solution We found the internal API to read it. This is what the 
screenlock
table uses But unlike almost everything else, it must run in the user context. This is not the same as finding something in the user’s homedir. AFAIK it’s one of the only things with that limitation
From what I’ve seen of Apple’s APIs, we are unlikely to find a mechanism that does not need user context.
Running as my local 
seph
user:
Copy code
$ osqueryd -S 
Using a virtual database. Need help, type '.help'
osquery> .mode line
osquery> select * from screenlock;
     enabled = 1
grace_period = 300
c
Right, I definitely had some confuse. I understand now. I could have sworn that I had 
screenlock
working outside of user context on osx >10.13 but seems I am mistaken.
so is it the position that, at the moment, this is an issue for the launcher to solve and not osquery? cause if so i'll go patch orbit
thanks for setting me straight on that @seph
s
As far as I know, osquery itself cannot solve this. I don’t know a way to avoid execing. So the user context thing needs to be outside osquery. (Someone might figure out something, but that’s hard to predict)
I don’t know much about orbit. It could theoretically work, but I can’t speak to the intent/vision fleet wants.
Good luck!
2 Views
Open in Slack
PreviousNext
Powered by