 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 or 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 D-Bus because I basically started building this as a flat pack 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 in 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. Like many organizations are using things like, say, 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 that 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 a 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 for, like, once we start piping this sort of access through here. So I skipped a little bit on the, there is a D-Bus interface for getting a lot of the OS data on here. I think I might have gotten a couple of 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 D-Bus. So basically, if it's exposed with D-Bus on the base system, then it's possible for a monitoring tool that is Sandbox to be able to read the data. So I've been just basically going through all the different sources in D-Bus, looking at the privileges required for those things, what's exposed through D-Bus, 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, say, 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 Silver Blue basically is a different package manager for this purpose, because if you try to access package kit from Silver Blue, it doesn't really talk to anything. And then, so the strategy here is to basically look for, is to configure the system so that it's automatically polling 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 branch of the, or a fork or a branch of the tree that you're currently on that has the update and that you'll, you're expected to reboot into. So starting with Silver Blue, because this is what I run, even though I think I'm the only person at my company who runs it right now. The, we can basically talk to LibOS Tree over D-Bus. It's really well exposed over D-Bus, basically everything for Silver Blue and OS Tree happens over D-Bus 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 OSes are installed, because I'm sort of skipping that stuff 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, how to, 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 gonna 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 D-Bus pumps out when you actually ask LibOS Tree for what the stage update data is, and you can see here that it's basically saying that 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, this seems to be the best interface on D-Bus for talking to DNF and YUM. My understanding is that a lot of the PackageKit stuff is going away, and a lot of the abstraction that it created is getting collapsed, 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 if it were 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 PackageKit, and that will tell us if there is anything going on there. This data is 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 PackageKit 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 PackageKit 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 in silver blue. So hopefully this is like something that we deal with in the meantime. Another thing is firmware on the system. The, 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 to 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. We have, 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 update, whether the system is configured to stage updates automatically because if you turn off auto updating stuff then you're not going to 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 doesn't, 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. Like 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. Like 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 is not trying to maliciously deceive the process. Like 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 account's interface on the box. That allows a 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 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 screensaver 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 like, is the machine compromised? Oh, I duplicated the slide. Sorry, we've already done that. This is mostly gaps in this because I really like a way to do RPM verification as part of checking the system as an affirmative confirmation that the virus scanner, 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 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 other than just letting OS tree tell me that it looks good, which might be enough. And then the last thing is there are some interesting root kit 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 like 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 root kit? This one? So this is not a root kit. In fact, it would be interesting if it detected other monitoring things as root kits because they're kind of like that. Some of them, and the reason why I call them root kits 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 that, and it's just, I just don't like the idea of like 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 in 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 that 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 10. 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 two ridiculous things in the box. Have you looked at InSpec at all? No, I haven't. 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 like contrast or overlap between what you're doing. 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 you think you're talking about? Yeah. One of the things is like 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, because 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 bothers them to there's not a DBS interface for this or the DBS interface for this is not good enough. So I think the approach you mentioned of oh, you might have a demon running on the host that's more privileged. I think it could be interesting if you took that approach and add a demon to expose the information you need over DBS and then on the other side you write it through. I think that would be a very nice privilege separation thing. Yeah, and that would achieve a lot of the goals that I have because one of the other things that I noticed 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 Fireworld.de I suspect you could probably ask upstream why is that restriction in place? I assume you just pulk it. Yeah, that's probably. So you could also just change the pulk it config on the host with whatever config management you have and leverage that because there's probably no reason why the state needs to be protected. Mm-hmm. I guess we'll break. Yeah, thank you. No further questions? Thank you, David.