[apparmor] [PATCH] profiles: Grant access to systemd-resolved in the nameservice abstraction

John Johansen john.johansen at canonical.com
Thu Oct 13 14:25:56 UTC 2016


On 10/12/2016 02:55 PM, Christian Boltz wrote:
> Hello,
> 
> Am Mittwoch, 12. Oktober 2016, 14:31:13 CEST schrieb John Johansen:
> ...
>> atm I think I am in favor of wrapping it in the conditional and
>> defaulting that conditional to false.
>>
>> The ubuntu patch then changing the conditional to true. This way
>> the information is being carried upstream. And only the distro
>> specific tweak is out of tree.
> 
> That sounds like a good idea, but... -
> 
> 
> If you look at utils/test/test-parser-simple-tests.py, you'll notice
> 
>     # testcases with various unexpected failures
>     syntax_failure = [
>     ...
>        # Syntax Errors caused by boolean conditions (parse_profile_data()
>        # gets confused by the closing '}')
> 
> followed by a list of all files in parser/tst/simple_tests/conditional/ - 
> except those with EXRESULT FAIL because at least those fail correctly 
> ;-)  (actually they fail for a different reason, but hey, they fail ;-)
> 
> So if you add any boolean condition, expect aa-logprof etc. to break 
> completely :-/
> 
> I'm aware of this since I wrote the test that checks against 
> simple_tests, but it has low priority because nobody seems to use 
> conditionals in practise. At least I never received a bugreport ;-)
> 
> Unfortunately fixing this isn't easy - the tools will probably need to 
> handle a "stack" of parenthesis ("I'm inside 'if $foo'") or something 
> like that. (Besides conditionals, that stack should also handle 
> owner { } and audit { } blocks, and also nested child profiles.)
> 
> To make things even worse, this major code change will probably have to 
> happen in an area of aa.py which is hard to cover with unit tests.
> 

well we are going to have to start fixing this, our plans for policy
versioning and "support" of new features on old parsers rely on boolean
conditional support

> 
> For now, a possible workaround could be to abuse variables. The upstream 
> code could have something like
>     @{RESOLVED_DBUS_SOCKET}=""
> and Ubuntu could set it to the real dbus socket. I know this is ugly 
> (and it also means not to use abstractions/dbus-strict), but it's still 
> better than breaking all aa-* tools.
> 

I'd rather not do this


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20161013/2d9fd2fa/attachment.pgp>


More information about the AppArmor mailing list