=== mirespace_ is now known as mirespace
=== Unit193 is now known as JackFrost
[11:52] <mpiano> Hi again ebarretto. I see the cvescan db for Xenial is still stale, any update on that?
[12:09] <ebarretto> mpiano, we are not updating the json for xenial and trusty for now. 
[12:52] <grimmware> oh is cvescan not expected to work for ESM?
[12:56] <mpiano> ebarretto, they have been updated with CVE/patch data available via the ESM channel until Feb 10th. Is that going to stop? If so, may I ask why? I think Xenial still has a few years of ESM support.
[13:00] <grimmware> On an entirely unrelated note, has there ever been any discussion on disabling unprivileged eBPF by default on Ubuntu? It's no big deal for us because we're using configuration management to disable it, but as a mitigation it pretty much closes off the sidechannel used on quite a large quantity of nondeterministic kernel exploits, but also there seems to be an eBPF verifier bug at least once every 6
[13:00] <grimmware> months and whilst I'm an avid eBPF user, I trust the verifier in the hands of an unprivileged user about as far as I can throw a house
[13:01] <grimmware> (I appreciate that the former doesn't necessarily close the vulnerabilities but it *does* tend to mean that out-of-the-box exploits don't work any more and engineering a working exploit is quite a lot more difficult)
[13:46] <mdeslaur> grimmware: we've moaned and whined each time a new exploit came out and have mentioned disabling it, but we haven't had any serious discussion about it
[13:47] <mdeslaur> amurray, sbeattie: perhaps we should see how feasible it would be ^
[13:48] <mdeslaur> While I haven't researched it at all, I have a funny feeling it's going to be hard to do
[13:54] <mdeslaur> grimmware: I think you can use kernel.unprivileged_bpf_disabled locally though if you want
[13:54] <grimmware> mdeslaur: yeah we are, I guess I was just kinda curious as to whether it was considered and how viable it was
[13:54] <grimmware> mdeslaur: I'm guessing the problem is whether people are using the feature out of the box and if disabling by default is considered a "regression" by end users?
[13:55] <mdeslaur> well, we wouldn't be able or willing to do it in stable releases, but that doesn't mean we couldn't do it for new releases
[13:55] <grimmware> ah yeah ofc
[13:56] <mdeslaur> we just need to figure out what would break that assumes it's turned on by default as that is the upstream default
[13:56] <grimmware> that doesn't sound easy :P
[13:57] <grimmware> I mean I guess that's determining if any packages in the official repos will attempt to load programs as a regular user?
[13:59] <mdeslaur> wait a sec, my focal laptop has it set to "2"
[13:59] <mdeslaur> maybe we did change the default?
[14:00] <grimmware> !
[14:00]  * mdeslaur checks impish
[14:00] <mdeslaur> impish also seems to have kernel.unprivileged_bpf_disabled = 2
[14:01] <grimmware> oh that is very cool
[14:01] <grimmware> some blindness to this on my front because getting people to upgrade to newer releases is like pulling teeth
[14:02] <mdeslaur> oh huh, looks like we did https://ubuntu.com/blog/whats-new-in-security-for-ubuntu-21-10
[14:02]  * mdeslaur is an idiot for not carefully studying amurray's blog posts
[14:06] <grimmware> I dunno man, I'm the guy who waded in and started asking questions without actually checking changes in newer releases :P
[14:06] <grimmware> that's pretty awesome though!
[14:07] <mdeslaur> hehe, yes, it is :)
[14:29] <mpiano> anyhow, going back to the cvescan database topic, would anyone know the answer for this question of mine?
[14:29] <mpiano> > they have been updated with CVE/patch data available via the ESM channel until Feb 10th. Is that going to stop? If so, may I ask why? I think Xenial still has a few years of ESM support.
[14:50] <grimmware> ^ I'm also interested to know this
[14:57] <ebarretto> grimmware, as you probably saw cvescan is no longer being maintained, it has plenty of issues reported in the tool itself and we also are aware of issues on the json file generation. We instead are advocating for the use of our OVAL data. 
[14:58] <grimmware> I had no idea it was no longer being maintained :(
[15:03] <grimmware> ebarretto: are you aware of any tools that can take OVAL data and a package manifest for a host to produce a list of applicable vulnerabilities?
[15:05] <grimmware> my experience with using oscap directly on a host is it absolutely slams resources whereas cvescan allowed us to performantly get reports on hosts by having them submit manifests to be parsed centrally
[15:07] <ebarretto> grimmware, have you tried oscap with manifests? 
[15:08] <grimmware> no I didn't know that was a thing it could do!
[15:09] <grimmware> having a look now
[15:15] <ebarretto> grimmware, https://ubuntu.com/security/oval for OCI images that is possible, not sure if it is your case though 
[15:16] <grimmware> ebarretto: shoudl be able to produce my own manifests with dpkg though, right?
[15:16] <ebarretto> grimmware, yes 
[15:16] <grimmware> cool, I think we can probably rework our setup to utilized oscap and the OVAL files instead then :)
[15:17] <grimmware> thanks for the help!
[15:26] <grimmware> ebarretto: sorry I might just be being dim here but the manifest instructions for https://ubuntu.com/security/oval tell you to download the manifest and then the following commands don't actually use it at all
[15:29] <ebarretto> grimmware, you don't need to specify it, the OCI OVAL file has the bits on using the manifest file. 
[16:30] <sbeattie> grimmware: unprivileged BPF disabled by default> yes, there is frankly ample evidence that that is the right stance to take and I'm hopeful we can get that in place sooner rather than later; having it disabled in impish let us see if it breaks anyone's expectations -- so far we've not heard anything.
[16:30] <sbeattie> So I'm hopeful that we can backport that config change back to older releases in the not too distant future.
[16:32] <grimmware> I'm interested to know what some of the difficulties around maintaining the cvescan databases actually were because I can tell from an early look that the OVAL stuff is *not* going to meet the same purpose for us without significant development work, so I'd like to understand what pitfalls there are so we don't fall into the same ones :P
[16:34] <grimmware> Like, being able to submit a manifest and have an output that told us what the CVE was, what the assigned severity was and what the target version for the fix is was exactly what we needed as we were able to tool it to work in a centralised way and generate telemetry for our entire fleet *and* produce actionable tickets and metrics from it
[16:36] <grimmware> I mean even just some way of being able to semantically parse out metadata from the USN RSS feed would be enough I think simply because we'd then just need to write the code to compare ubuntu release and then compare package versions, but the only way to get that data out programatically is to scrape the USNs which seems like a pretty fragile way to go
[16:36] <grimmware> the moment formatting changes it'll break
=== arif-ali_ is now known as arif-ali