Hi, so one of the things that we're working on at my company is as we expand and deal with clients that have lots of requirements is figuring out how to manage the security of our desktop deployments. These are pretty well established as practices and tools for if you're using something

like Windows, a little less so, but still pretty established for things like Mac, but the tools on the Linux side are a little limited, especially if you want to restrict the privacy of our control for the privacy of the users so that you don't

necessarily put rootkits on the box. So this quickly turned into how I learned to love doing everything over DBUS because I basically started building this as a Flatpak application so that it can launch by default on the system and that allows an approach to sandboxing where I can open up individual interfaces and access the data in ways where even though the automatic monitoring tool

is eligible for getting automatic updates, I didn't want it to be able to just get arbitrary privileges as those updates occur because I don't know how many people here have these sorts of agents on their machine, but in a lot of cases they can

do things like turn on your camera, take screenshots, and even if they don't do that out of the box, they often have a path to being able to do that where they could just, say, update their software and then actually enable additional privileges because they're typically just running as shell scripts running as root or Python things running as

root on the box with kind of sketchy verification of where the actual software updates are coming from. So I'm going to talk a little bit about the constraints that we're working on in terms of what we're trying to accomplish and what I'm not trying to accomplish with this work and then talking about the kind of core aspects that we're trying to watch

on these machines. We need to be able to establish what the machine is both locally and on the network, whether the software on the machine is actually up to date from a security perspective, whether the machine is well defended from a configuration perspective for local and remote attackers, and looking for indicators that the machine might be compromised.

So starting with the constraints, this is all about avoiding some of these undesirables here because a lot of this is super easy if you don't care about basically installing a root kit on people's box and then giving IT access to that.

In a lot of cases, also, the other issue we've run into is fragile interfaces to data collection where some of the agents that we've run will update the version of Fedora and suddenly the agent breaks because they're often relying on things like running a shell command, parsing the data coming out of it. It's unbelievably nasty what's in a lot of the monitoring tools out there.

And also our goal is not necessarily to be doing configuration management of the machines in the sense of just deploying configuration because a lot of tools solve this sort of other half of the problem. Many organizations are using things like Chef even on the desktop, and that allows you to push out configuration to the machines, but it's not actually that great at monitoring

whether the configuration of the machine is actually aligned with the actual compliance and security controls that you want to implement. So in terms of what we're trying to accomplish, it's basically we want it to be able to auto update, we want it to run on Fedora boxes, we'd probably like it to be able to run

on other distros as well without having to do a release specific to each distro. That's another reason that Flatpak is interesting here. We want it easy to install. That's another Flatpak thing. And I happen to be a Silverblue fan, so I wanted it to work well with that sort of system. And there are monitoring tools that do other ridiculous things like just downloading files

and writing them out to USR, and you just can't have that on a system that's running on something that's based on libos tree. So basically within these constraints, I wanted to accomplish this sort of data collection. So the first thing that we need to be able to establish is actually what the machine

is. We need to be able to identify a unique identifier for the machine for tracking in any monitoring system. We need to be able to identify how the machine is going to be appearing on the network if we're trying to correlate network activity or access controls to the machines that are enrolled in the system.

And we also need to be able to identify the basic installed software on the machine in terms of the OS major version, and so we know kind of where the foundations should be expected for other updates, or whether the system is even on an OS that is still getting updates. Because later we'll check whether there are updates pending for the OS, but Fedora 22,

for example, doesn't have any pending updates. But that doesn't necessarily mean it's secure. So the first thing is just getting the machine ID. This one's actually easy. If you read this from Flatpak, you actually get the real machine ID. I was kind of worried about this initially, but that was easy enough.

The next thing is to actually get the release the machine is running on. Turns out this is really interesting when you run it in Flatpak. Because you're starting from the sandbox. It's trying to homogenize the view of the system in a way where, in fact, it's almost

ridiculous that I'm trying to do this from Flatpak, because I'm trying to read all these different properties of the system. But I'm actually getting pretty far on this. But if you start looking at other interfaces, you can actually get this kind of data. Once we start piping this sort of access through here. So I skipped a little bit on the...

There is a DBUS interface for getting a lot of the OS data on here. I think I might have gotten a couple slides out of order. But one of the other things that we're looking at is the identity of the machine on the actual network.

Where we want to be able to get things like the MAC addresses. If you run this sort of thing from inside the Flatpak, again, it's going to homogenize everything. It's going to give you a sort of fake network interface, if you have any network interface at all with a lot of this data. But one of the nice things with Flatpak is we can basically poke holes in the isolation

at the interface level with DBUS. So basically if it's exposed with DBUS on the base system, it's possible for a monitoring tool that is sandboxed to be able to read the data. So I've been just basically going through all the different sources in DBUS, looking at the privileges required for those things, what's exposed through DBUS, some things aren't.

The next thing I wanted to look at is if we've established the basic configuration of the machine, like we know it's running on Fedora 30, we know the MAC address of the machine, we know the machine's machine ID in terms of a unique identifier for updates,

we now have a baseline for knowing is this machine at least installed with a base system that is actually supportable. So once we've established that, we can actually start looking at whether the machine is running up-to-date software on it. Because one of our kind of compliance goals is that if there's a security update, it should be rolled out to every one of our desktops if it's an extremely important

update within a week and if it's a regular security update within a month. So this creates some new challenges, being able to look for the updates here, because the updates interfaces for this are pretty varied and they're kind of changing and

some of the things that have been done before to homogenize the interfaces are not sustained right now. So we're looking at possibly different package managers, different concepts for security versus regular updates in terms of how they expose that information. Even the difference between regular Fedora and Fedora Silverblue basically is a different

package manager for this purpose. Because if you try to access package kit from Silverblue, it doesn't really talk to anything. So the strategy here is to basically look for is to configure the system so that it's automatically pulling update data and staging the updates for install so they're ready

to install and then look for that state. Because you can configure the offline updates on Fedora to auto-prepare that. That's what it does out of the box with the workstation. And then with libos tree, you can also configure that to automatically stage the updates so that when it pulls new metadata down, it will basically create a fork or a branch

of the tree that you're currently on that has the update and that you're expected to reboot into. So starting with Silverblue, because this is what I run, even though I think I'm the only person at my company who runs it right now. We can basically talk to libos tree over Dbus.

It's really well exposed over Dbus. Basically everything for Silverblue and OS tree happens over Dbus in terms of the clients and things talking to it. And we can basically go to the system. One thing that's not shown on this is that you would want to actually query initially

for what the OSs are installed, because I'm sort of skipping that step and showing the querying of the OS that's currently booted. But once you've established what OS is currently booted, you can look for the actual cached update data, and it will show data about the updates that are on the way. So if this is not empty, basically, we know there are updates on the way.

And I'm actually having trouble finding how to discover when it's a security update. Because there's no documented interface for doing that, but it does it on the command line. So I'm basically going to have to wait for the next security update and reverse engineer

how it's exposing that data or dive into the source code of that. Because I don't really see an indicator on this here. And this is, I guess, a general disclaimer that I'm working through this challenge, too. So if anyone has ideas for doing this sort of sandboxed system monitoring,

I'm definitely open to hearing suggestions around that. So this is the data that Dbus pumps out when you actually ask libos tree for what the staged update data is, and you can see here that it's basically saying the sensor proxy is getting updated from 2.7 to 2.8, and OpenConnect is getting updated from 8.02 to 8.05.

PackageKit is currently, seems to be the best interface on Dbus for talking to DNF and Yum. My understanding is that a lot of the package kit stuff is going away, and a lot of the abstraction that it created is getting collapsed, and so that things like Software Center will be directly talking to DNF and Yum.

And so I'm not sure how this interface will be changing, and I'm kind of worried that it's a little brittle in that sense. But it does provide a way to look for updates that are ready to go when you are looking at DNF and Yum as exposed through package update. For the last, I don't know exactly when Fedora changed. Maybe it was about five or six releases ago.

But it changed to the default being to stage the updates, and then encouraging the user to reboot so that the updates are installed offline. And then those updates get applied as part of a clean, rebooted environment. And then it reboots again into the OS, having installed the updates. So if we're going to look for what updates are staged for the system,

from that perspective, we can actually look at the offline prepared update data for package kit. And that will tell us if there is anything going on there. This data's not very rich, it just says update prepared, that's a Boolean.

So I haven't figured out how to actually identify through any of the package kit interfaces, whether there's a security update pending. I have confidence for the LibOS tree I'll be able to do that. But I'm not as certain for the package kit without, say, comparing the data I get out of this to maybe other data I can fetch online on a monitoring system.

So, but that said, I'm hoping the world moves to LibOS tree and So hopefully this is like something that we deal with in the meantime. Another thing is firmware on the system. All of our laptops have firmware support from the Linux vendor service around that, and this provides an interface where, again,

I'm kind of skipping one step here, where there is a step where you basically have to fetch the device IDs from elsewhere in this interface. And then you can walk through each of the device IDs, you can ask the firmware updater whether there are any updates pending for that device ID, and if there are any devices that have firmware updates

pending, then it's probably a good idea to include that as a potentially security update, because most of the firmware updates, I'd say, for my laptop are security motivated. And of course you have all those little devices that you plug in, like the Logitech dongles and things like that, and

those can have security updates too. There was a really nasty bug in one of the Logitech dongles a few years back. And this is getting really good on Linux, this firmware update stuff. So I'm kind of excited about being able to query in one interface without having to probe different devices to get that kind of data.

I have a few gaps in the work that I've done so far with this. It's hard to verify the metadata freshness for the firmware updater tool. I haven't found an interface for that. And I'm also looking to verify that auto preparation of updates is enabled, because libos tree will tell me that an update is staged, but

it doesn't necessarily tell me as easily the configuration for whether the system is configured to stage updates automatically. Because if you turn off auto updating stuff, then you're not gonna ever enter a state where you have an update ready to go. At least unless the user manually triggers that.

But the whole idea here is to not have to have the user have to explicitly do anything for you to watch the security of the box. So in terms of one of the next areas is, is the machine well defended in the sense of how do we

make sure that various configurations are in place for things like the firewall? This was unfortunate because I'm able to actually query this, and I found exactly where to get the data. But there's a very rigid set of security constraints around the interfaces to firewall D. And they basically blanket require admin for any conversation with firewall D.

You can't even check that it's running, at least by talking to it. I might have to resort to just seeing that the service is running in, say, system D. Because I'm really trying to avoid having to do privilege escalation in order to collect this data.

But that's that for that one. Another thing is, I'm not a fan of this, but a lot of our compliance stuff requires some sort of virus scanner running. Usually not for the Linux systems. A lot of it's for the sake that it's not actually that ridiculous. Because it's really treated more like vaccinating your computer base,

in the sense that if anything malicious lands on an individual machine, even if it's not malicious to that machine, it's possible to not have it propagate. That if I, for some reason, download a customer's files and it includes a virus in it for Windows or Mac, that I don't send that

on to someone who actually is running a system that might be vulnerable to it. This doesn't really deeply check whether this is really running. You could reconfigure the scanner to not be running, but have the daemon running in various ways. So it's not that deep of verification, but I'm typically assuming that the user's not trying to maliciously deceive the process.

This is really intended for things like employees. And then another thing is, we're required to basically have passwords for all the accounts to make sure that they're not actually automatically logging on to the system. And that is all harvestable from the accounts interface in the box. That allows us to password mode.

Zero means that there's a password set and automatic login, of course, false. This only gets about half of the criteria. It's interesting how some of the authentication configuration is split in Linux desktop world. Because there's a lot of configuration that is on the base system, on the system bus here, where it's the basic user account configuration.

But then the other half of the security is things like the lock screen configuration for how many minutes it takes for the lock screen to appear, whether the lock screen requires a password. And that's all configured within configuration stored in the home directory. Whether you're using X screen saver or you're using the G settings data for

that, that makes it kind of hard. Because at least for G settings style data, Flatpak tries to isolate all of that and they're trying to basically have it where the settings for an application are stored with that application. Because it's assumed that you're basically configuring just the application.

So I'm gonna have to try and figure out some of that. That's one of the gaps is that I can't check the screen lock times yet with this, even though I know exactly where the data is stored. I can't find anywhere where it's exposed over some of the D bus stuff. And I'd like to have the firewall check occur in a way where I don't need to

escalate privileges in order to verify that the firewall is running. And the last area is, is the machine compromised? The, I duplicated the slide. Sorry, we've already done that. This is mostly gaps in this because I'd really like a way to do RPM

verification as part of checking the system as an affirmative confirmation that the system has integrity rather than looking with a virus scanner for signs that the system has been compromised. That's a really slow process to run and it requires, and it doesn't require a lot of privileges on the system.

But it has fairly noisy data and doesn't have very good interfaces, at least from a sandbox perspective. The LibOS Tree signature data is right there in the D bus interfaces. But I haven't found great ways of consuming that to verify that the, other than just letting OS Tree tell me that it looks good, which might be enough.

And then the last thing is, there's some interesting rootkit detection systems that basically look for signs that the system has had something that has escalated privileges installed in a surreptitious way. That definitely is gonna require some sort of escalated privileges.

And I might need to actually create some sort of corresponding daemon for this that is able to run some of that stuff in an escalated way that doesn't open up some of the security constraints around privacy that I'm worried about. And so that is, so I'm happy to take questions from people.

And also, I'd love to hear more about other experiences people are having with Linux desktop deployments in corporate environments and the ways that you're working with maintaining the security of that infrastructure.

I have a question. How do you prevent your application being detected as a rootkit? This one? Yeah, well, this is not a rootkit. In fact, it would be interesting if it detected other monitoring things as rootkits, cuz they're kind of like that. Some of them, and the reason why I call them rootkits,

is not just because of the level of privilege they have, but a lot of monitoring tools try to embed themselves in the system in a way that makes it hard to remove, and I just don't like the idea of sketchy stuff running as written on my box. You had a question over there.

Hi. Hi. Aren't there any tools already that do that roll out of desktops, ISOs, and stuff, and companies like FAI and M23? And what's the difference of your approach? So FAI and M23, I haven't heard of those applications.

Are those desktop monitoring applications? No, it's more like rolling out desktops in a company, but also sending security updates, stuff like that. I'm not familiar with those applications. A lot of the tools that I've looked at are the ones in the Fedora space that are things that integrate into the, I'm trying to remember,

the Kerberos implementation that supports a group policy style infrastructure. There are things that plug into things like free IPA and other configuration tools for rolling out some system configuration. Those tools I find lacking because they are focused entirely on

pushing out configuration and not actually verifying that the configuration is in place, and in our case, we really don't need a lot of roll out of configuration, and in fact, we often don't want to force a specific config on users. We don't necessarily want to force the screen lock time to be exactly five

minutes, we might want to say that screen lock needs to be less than ten. And the user can have whatever configuration they want that complies with it, but we don't necessarily want to roll out a specific policy. The other tools that I've looked at for monitoring, some of them are

commercial and they have a lot of the problems that I mentioned earlier. Like some of them run on Python 2 and just do ridiculous things in the box. Have you looked at InSpec at all? No, I haven't. Okay, InSpec is an open source tool that is now owned by Chef,

the software company, and it was originally developed for compliance monitoring. And so it's a thing that will then introspect the system state on a regular basis, and I was curious if there was contrast or overlap between what you're- So it's called InSpec? Yeah. Yeah, this is not something I've encountered.

Is this a relatively established project? Yes. Okay, I have looked at Chef itself for this purpose, but Chef itself doesn't really do this. No, yeah, this is the component that you want to have actually validate, do that exact verification that I think you're talking about. Yeah, one of the things is how, what their Linux support looks like.

Because I often find that these sorts of tools list Linux, and then they often have really weak support, or often it's server oriented. Maybe I should catch you after- Yeah. Cuz I'd love to learn more about some of the tools that are in place for this.

Something else that could be interesting, it sounds like for a lot of the things you say that you can't do, it boils down to there's not a DBOS interface for this, or the DBOS interface thus far, this is not good enough. So I think the approach you mentioned of oh, you might have a daemon running on the host, that's more privileged.

I think it could be interesting if you took that approach and add a daemon to expose the information you need over DBOS, and then on the other side you write it through. I think that would be a very nice product separation thing. Yeah, and that would achieve a lot of the goals that I have, because one of the other things that I notice with a lot of these clients is

that because they need some privilege for a little bit of what they do, they basically just expand the privileges of the entire application up to and including it uploading the reports with HTTP. Yeah, and the other thing is for stuff like firewall-d, I suspect you could probably ask upstream, why is that restriction in place? I assume you just bulk it. Yeah, it's probably bulk it. So you could also just change the bulk of config on the host,

with whatever config management you have, and leverage that. Cuz there's probably no reason why the state needs to be protected. Mm-hm, I guess we'll break.

Yeah, thank you. Any other questions? Thank you, David.