Hi there! I am wondering if someone could help me ...
# fleet
a
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
Hi! If you check the host’s installed packages through Fleet, does
augeas-lenses
show up there?
a
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%';
k
And what happens if you query for a specific config?
Copy code
SELECT * FROM augeas WHERE path='/etc/ssh/sshd_config';
a
😞
k
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
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
Are you using packages generated by Fleet, or vanilla osquery on the host?
a
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
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
The value for that query is:
Copy code
"host_hostname","name","value"
"radiance","augeas_lenses","/opt/osquery/share/osquery/lenses"
m
Can you check if
/opt/osquery/share/osquery/lenses
actually exists? You mentioned that you installed
augeas-lenses
using
apt
.
a
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
either way. I suspect that osquery is looking for the lenses in the wrong location.
a
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
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
Just following up. Are you still experiencing the issue with augeas lenses?
a
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.