https://github.com/osquery/osquery logo
Powered by
#fleet
Title
a

Andrew Zick

12/09/2022, 9:26 AM
Hi there! I am wondering if someone could help me with a variation of this problem, where osquery is unable to read the 
augeas
table. https://osquery.slack.com/archives/C08V7KTJB/p1668118967997209 I’m trying to use FleetDM live queries and additional queries to look at 
augeas
on a Linux Mint device, but even just 
SELECT COUNT(*) FROM augeas
returns 0. I’ve had the user install 
augeas-lenses
locally which has fixed this issue for me before, but it had no effect here. 
osqueryi
run locally on the machine is able to return results. Has anyone run into this problem before or have any ideas for potential solutions? osquery: 5.2.2, Fleet: 4.13.2
When I say that I’ve run into this problem before, I’ve encountered it both when running live queries on Ubuntu and Mint devices and when running 
osqueryi
locally on the same devices I’ve managed to fix it every time by having the user install the augeas lenses (
apt install augeas-lenses
). This is the first time that hasn’t worked 🙁
k

Kathy Satterlee

12/09/2022, 4:11 PM
Hi! If you check the host’s installed packages through Fleet, does 
augeas-lenses
show up there?
a

Andrew Zick

12/09/2022, 5:58 PM
Oh doh, you’re right, that’s a good thing to check. Looks like it did install as the name is “augeas-lenses”. Query was 
SELECT * FROM deb_packages WHERE name LIKE '%augeas%';
device appears to have augeas-lenses installed.txt
k

Kathy Satterlee

12/09/2022, 6:03 PM
And what happens if you query for a specific config?
Copy code
SELECT * FROM augeas WHERE path='/etc/ssh/sshd_config';
a

Andrew Zick

12/09/2022, 6:07 PM
😞
k

Kathy Satterlee

12/09/2022, 6:08 PM
I figured, but had to check. My instinct here is that it's a permissions issue since it works with 
osqueryi
, but not 
osqueryd
, but let me dig in to it.
a

Andrew Zick

12/09/2022, 6:10 PM
More info that might be helpful, we have Cloudflare in the mix for handling CDN/web traffic stuff, not my forte, and previously I’ve had to tweak or turn off SQLi protections that were blocking queries from running. I don’t think that’s what’s happening here but it is part of our setup.
k

Kathy Satterlee

12/09/2022, 6:10 PM
Are you using packages generated by Fleet, or vanilla osquery on the host?
a

Andrew Zick

12/09/2022, 6:12 PM
I believe we use packages generated by Fleet (project was set up by someone who has since left the company). I had the user test both 
osqueryi
and 
osqueryd -S
locally on their machine and they both successfully return results, again just for more info.
Poking around our internal docs: “Osquery lacks an auto updater and requires setting a large number of configuration settings to work for our use case. We use Orbit (a sub section of the FleetDM repository) as our osquery runtime and auto updater. Also included in FleetDM are commands to package Orbit into OS specific installers. For Windows and Debian Linux a unique install package is generated per customer.”
s

sharvil

12/09/2022, 7:05 PM
Another thing to check would be flags — from fleet can you run this query: 
select name, value from osquery_flags where name = 'augeas_lenses'
and see what the value of it is?
a

Andrew Zick

12/09/2022, 7:06 PM
The value for that query is:
Copy code
"host_hostname","name","value"
"radiance","augeas_lenses","/opt/osquery/share/osquery/lenses"
m

Michal Nicpon

12/09/2022, 7:18 PM
Can you check if 
/opt/osquery/share/osquery/lenses
actually exists? You mentioned that you installed 
augeas-lenses
using 
apt
.
a

Andrew Zick

12/09/2022, 7:19 PM
Actually, I’ve described that incorrectly. The user installed it via dkpg, iirc, I’m just accustomed to doing it via 
apt
. I’ll go ask for confirmation from the user.
m

Michal Nicpon

12/09/2022, 7:20 PM
either way. I suspect that osquery is looking for the lenses in the wrong location.
a

Andrew Zick

12/09/2022, 9:14 PM
Alright, I’ve been given a screenshot of what was in the 
/opt/osquery/share/osquery/lenses
folder
I have an update. Separately I was working on a different additional query, made and deployed a change to it about 30 minutes ago, then did a refresh of the data what I was getting from this Linux Mint device. I now get 55459 as my result for 
SELECT COUNT(*) FROM augeas
😐 which is plenty reasonable. Works in both live query and in the additional query results that we process + store in a database. What I changed for unrelated-to-augeas additional query, it changed from:
Copy code
SELECT COUNT(*) AS result FROM disk_encryption WHERE encrypted = 1
        AND name IN (SELECT device_alias FROM mounts WHERE path = '/');
to:
Copy code
SELECT COUNT(*) AS result FROM mounts WHERE path = '/'
        AND device_alias IN (SELECT name FROM disk_encryption WHERE encrypted = 1);
All I did was swap the outer and nested query 😐 I’ll post an update on Monday to confirm whether or not it’s still working. Have a great weekend and thank you for helping me with this!
r

roberto

12/09/2022, 11:34 PM
Thanks for the update Andrew, I think we will also follow up and investigate why a separate query might have affected yours and what we can do to prevent that in the future. Hoping to hear from you on Monday! have a great weekend
m

Michal Nicpon

12/14/2022, 5:18 PM
Just following up. Are you still experiencing the issue with augeas lenses?
a

Andrew Zick

12/14/2022, 9:19 PM
Ah sorry, I must have missed my reminder to update y’all on this. I can confirm that I am still getting (correct) results from both additional queries and that it doesn’t appear to have been a fluke, other than that I have no idea why changing the seemingly unrelated query has fixed this.
Powered by