| === chris14_ is now known as chris14 | ||
| laiello | Hey folks, I was looking to see if someone here has implemented an AppArmor init profile to create a default-deny for all [unknown] binaries on the OS. We've got it working but are running into quite a bit of friction managing that list. As such, we're looking into developing new utilities to enable us to centrally manage/update/distribute those | 17:08 |
|---|---|---|
| laiello | allow-lists in near-realtime (a big chunk due to our internal design+Chef). I was wondering if anyone else has done this at scale and was interested/able to compare notes on how they streamlined the developer experience while staying within the regulatory compliance lines. | 17:08 |
| pombreda | Hiya :) What the license for the security data at https://ubuntu.com/security/notices (and the usn-db dump) | 17:51 |
| pombreda | And the license for https://ubuntu.com/security/oval reports itself as GPL and I do not know what to do for data with a GPL. | 17:51 |
| pombreda | Who to talk to? | 17:51 |
| pombreda | FWIW, we aggregate this in our little project at https://github.com/nexB/vulnerablecode/blob/main/vulnerabilities/importers/ubuntu.py and https://github.com/nexB/vulnerablecode/blob/main/vulnerabilities/importers/ubuntu_usn.py and we like to have a license for that! | 17:51 |
| pombreda | Debian did not have a license ... but that was clarified at https://github.com/nexB/vulnerablecode/blob/main/vulnerabilities/importers/debian_oval.py | 17:52 |
| sbeattie | pombreda: hey, thanks for the question, and apologies that we don't have explicit terms on this stuff. In general, we want people to be able to consume, integrate, aggregare, and use the data presented in tools like nexB (so long as the data is represented accurately). | 18:19 |
| sbeattie | I'll poke people internally about getting more explicit statements in place. | 18:19 |
| sarnold | laiello: there's been a handful of people who have tried to put together full-system apparmor confinement but never anything very public :( | 21:00 |
| jjohansen | indeed, we are slowly getting to where it is more feasible but it is difficult atm | 21:22 |
| laiello | That's a bummer, but consistent with others I've talked to. We'll keep chugging, and maybe we can break the not-very-public side of things. I know we were planning some blog series about it, but I'll see if we can maybe opensource the developer toolsets that we're designing as well. | 21:57 |
| sarnold | nice :D | 21:57 |
| laiello | I'm also kind of surprised to hear that though, do you know how have others tackled "CM-7(2) — Security safeguards must be implement which prevent program execution of unauthorized software - i.e. software whitelisting." for FedRAMP High Audits in relation to AppArmor? Is there another angle maybe we hadn't considered? | 21:59 |
| sarnold | I've not done that level of compliance myself but I'd always assumed those would be done via EVM / IMA sorts of things | 21:59 |
| laiello | Hmm, I know of them at a high-ish level, but how would EVM be used to prevent execution versus just logging/reporting? Is there something built-in or is it more of an subsystem that we would then integrate with to add that specific logic. | 22:15 |
| sarnold | laiello: I think that's "ima appraisal" https://sourceforge.net/p/linux-ima/wiki/Home/#ima-appraisal | 22:21 |
| sarnold | heh, does the kiwi thing not open in new windows by default? :) | 22:22 |
| laiello | No, a random mandatory chrome update/reboot I wasn't allowed to keep postponing:D | 22:22 |
| sarnold | *sob* | 22:23 |
| sarnold | I hate that so much | 22:23 |
| laiello | Just skimming through that last link you sent. Am I reading this right in that, if you combine IMA Appraisal with IMA/EVM Keyrings, you could just sign everything on the OS (and allow the canonical keys for example) and block execution of any unsigned binary? | 22:28 |
| sarnold | I think so | 22:29 |
| sarnold | I haven't got a clue how shell scripts, awk scripts, perl scripts, ruby scripts, python scripts, etc work.. | 22:29 |
| laiello | Yeah, that's been a gnarly mess so far =$ | 22:30 |
| laiello | So IMA seems smooth for a clean boot-up/maintaining the initialized version, but I'm not clear on first read that it would be compatible with continuous delivery as it would theoretically block replacing a binary with another one, even if its signed. Am I reading that right? I may just need to spend the rest of the afternoon reading up on these | 22:41 |
| laiello | subsystems to get a better understanding on how they work and interact. | 22:41 |
| sarnold | I always assumed there was some sort of middle-step to applying updates, eg you've got a staging environment where new packages get tested, and if they succeed, then you generate sigs for the packages, then push sigs and packages to all the production machines | 22:43 |
| laiello | Yes, that's how things would work - it would make sense to me that as long as they are signed correctly, the OS shouldn't care if a binary is suddenly replaced. | 22:44 |
| sarnold | *nod* | 22:45 |
| jjohansen | well, we really need better ties between IMA and MACs. AppArmor does a little bit where you can select different profiles based on IMA/EVM but, its really clunky and needs to be improved | 23:21 |
| jjohansen | this lets you have verified/safe and unsafe profiles and still run things | 23:21 |
| jjohansen | I have talked to mimi about improving it but we have never had the time to really sit down and hash it out | 23:22 |
| jjohansen | basically I want the IMA/EVM verifcation state to a given key to be used as a rule conditinal | 23:23 |
| jjohansen | IMA good with this key, you can have this profile | 23:23 |
| jjohansen | or you can get read access, etc | 23:23 |
| sarnold | IMA integration with apparmor sounds lovely :) yet another item for the todo list :) | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!