| jslarraz | Hey sdeziel, regarding iperf3 updates, they include fixes for different vulnerabilities as you can see from the USNs. The reasoning here is that iperf3 is a universe package and as such, security fixes are devoted to Ubuntu Pro (-esm). However, as fix for CVE-2023-38403 was already provided by Debian, we wanted to make it also available to all | 07:44 |
|---|---|---|
| jslarraz | Ubuntu users. In summary, the update in `-security` includes the fix for CVE-2023-38403, while the update in `-esm` include the fix for both CVE-2023-38403 and the issue published by upstream in their advisory https://downloads.es.net/pub/iperf/esnet-secadv-2023-0002.txt.asc | 07:44 |
| -ubottu:#ubuntu-security- iperf3 before 3.14 allows peers to cause an integer overflow and heap corruption via a crafted length field. <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-38403> | 07:44 | |
| sdeziel | jslarraz: OK thank you, I didn't notice there were another fixes (without CVEs) being bundled in the `-esm` version | 12:49 |
| === chris14_ is now known as chris14 | ||
| ahasenack | hi security, apparmor question | 18:22 |
| ahasenack | I have "abi <abi/3.0>," in the first line of a "modern" apparmor profile | 18:22 |
| ahasenack | but bionic doesn´t like that | 18:22 |
| ahasenack | Found unexpected character: '<' | 18:22 |
| ahasenack | is there a way to make it "compatible" with bionic, so I could use the same profile in all releases? Or I really have to remove it when building the package for bionic? | 18:22 |
| ahasenack | remove the line, I mean | 18:22 |
| georgiag | ahasenack: afaik you need to remove the abi line for bionic. jjohansen, can you confirm if there's any workaround? | 19:31 |
| jjohansen | ahasenack: to make it compatible we would need to cherry pick a patch back to bionic and do an SRU | 19:47 |
| jjohansen | its possible. All the patch does is ignore the ABI line so the profile can be parsed | 19:48 |
| ahasenack | jjohansen: and I can just remove the abi declaration for bionic, right? No need to add anything else? | 19:48 |
| ahasenack | to replace it? | 19:48 |
| jjohansen | ahasenack: yeah, I can just drop the ABI line | 19:49 |
| jjohansen | or stick a comment in front of it | 19:49 |
| jjohansen | # | 19:49 |
| ahasenack | will the comment make it be ignored where the abi statement actually means something? | 19:51 |
| ahasenack | or is it like include vs #include | 19:51 |
| ahasenack | (where both actually include something) | 19:51 |
| jjohansen | it will be ignored | 19:54 |
| ahasenack | ok, so where abi makes sense, I should keep it | 19:54 |
| ahasenack | tl;dr really use two different profile files | 19:54 |
| jjohansen | we did think about supporting #abi like include but decided against it | 19:55 |
| ahasenack | agreed | 19:55 |
| jjohansen | well it seemed like a good idea at the time with only 5 year support time frames | 20:08 |
| jjohansen | and we had planned ahead far enough to drop the ignore abi parsing into 2.13 | 20:09 |
| jjohansen | but now? | 20:09 |
| ahasenack | I meant the concept of using # for comments, except if they start with "include" :) | 20:10 |
| ahasenack | don't extend that to other exceptions like "abi" :) | 20:10 |
| jjohansen | yeah, its janky | 20:10 |
| jjohansen | no, where we are going is better conditionals and the ability to add some dummy parsing in policy | 20:12 |
| jjohansen | if !parser_supports(XXXX) { | 20:12 |
| jjohansen | ignore rule=^.*,$ | 20:12 |
| jjohansen | } | 20:12 |
| jjohansen | so that we can add some basic parsing to the base includes on how to ignore rule changes | 20:13 |
| jjohansen | it will start simple, but we need it, so we can keep policy unified | 20:14 |
| jjohansen | I would SRU that if I could, but the changes necessary to make the conditionals work, is too much | 20:14 |
| jjohansen | well maybe | 20:15 |
| jjohansen | we need to do something with these longer support windows | 20:15 |
| jjohansen | its something we will have to look at when it lands | 20:15 |
| ahasenack | these conditionals look like a big change | 20:18 |
| jjohansen | well, conditionals are actually already supported, but they are uhmm limited | 20:18 |
| jjohansen | so the base | 20:19 |
| jjohansen | if ... { } | 20:19 |
| ahasenack | in bionic? | 20:19 |
| jjohansen | is already in bionic | 20:19 |
| ahasenack | I still have to try to load this profile I'm working on on xenial | 20:20 |
| ahasenack | currently having problems launching a xenial vm | 20:20 |
| jjohansen | actually they are in lucid | 20:20 |
| ahasenack | found something funny in bionic's python3.6 because of this profile. It was denying /sbin/ldconfig when uuid was imported | 20:21 |
| ahasenack | and I was like huh? | 20:21 |
| ahasenack | so yeah, in bionic, python3 -c "import uuid" triggers ldconfig :) | 20:21 |
| ahasenack | would love a "if bionic" conditional :) | 20:22 |
| jjohansen | it exists, you can use it in the rules blocks of profiles but not with variables | 20:25 |
| jjohansen | if $var { | 20:25 |
| jjohansen | } | 20:25 |
| jjohansen | $var is a boolean var you define it in the preamble section like other variables | 20:25 |
| jjohansen | $var=false | 20:25 |
| jjohansen | $var=true | 20:25 |
| ahasenack | hm | 20:26 |
| ahasenack | so one way would be to generate this profile dynamically in postinst perhaps, detecting where I am, and setting var accordingly | 20:26 |
| ahasenack | is what you mean? | 20:26 |
| ahasenack | I don't suppose that var can be set dynamically based on conditions in the environment | 20:27 |
| jjohansen | the conditionals are capable of a bit more, but atm they can't be used in the preamble section, so not with the abi rule, around var definitions, ... | 20:27 |
| ahasenack | do I *need* the abi rule in later apparmor? Like focal+ all the way up to NN? | 20:28 |
| jjohansen | so unfortunately it won't work for abi rules, but you can use it for other rules | 20:28 |
| jjohansen | no its value can't be dynamic based on environment, what the parser supports, or what the kernel supports | 20:28 |
| jjohansen | we want to fix all that | 20:28 |
| jjohansen | yes, you will need the abi rule in future apparmor | 20:29 |
| ahasenack | ok | 20:29 |
| jjohansen | it is what declares the set of features the profile was built around, so adding new features in the kernel doesn't break applications with policy that hasn't been updated yet | 20:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!