[apparmor] Question about defining a profile name via @{exec_path} variable
John Johansen
john.johansen at canonical.com
Thu Jan 10 00:31:19 UTC 2019
On 1/9/19 3:59 PM, Seth Arnold wrote:
> On Wed, Jan 09, 2019 at 11:48:44PM +0100, Mikhail Morfikov wrote:
>> @{exec_path} = /usr/bin/keepassxc
>> profile keepassxc @{exec_path} {
>> }
>
>> # aa-complain usr.bin.keepassxc
>> ERROR: Profile for @{exec_path} exists in /etc/apparmor.d/some-app and /etc/apparmor.d/some-other-app
>
>> Should this happen? Should I avoid using the code
>> snipped to make profiles and use regular paths instead?
>
> I guess you'll have to decide if your abstraction to make it easy to
> change the location of binaries saves you enough trouble that it's worth
> no longer being able to use the python-based utilities. If you've built
> enough infrastructure around your tooling it might be easy to extend it to
> do whatever the python-based tooling does and you're missing. If you've
> not yet built much infrastructure around your abstraction, this might not
> be quite as compelling.
>
Well this is certainly allowed, and the python based tools should be able
to support it. Are you sure they weren't failing in the past? If so this
would be a regression.
With that said, I would be surprised the python based tools didn't handle
profile name execpath properly until recently. And come to think of it
maybe its handling it properly that has introduced this bug, as they are
probably failing to handle the variable while doing checking the path.
Adding cboltz so he should see this
More information about the AppArmor
mailing list