[apparmor] AppArmor and /etc/

[Tyler Hicks]

On 03/23/2018 12:10 PM, John Johansen wrote:
> On 02/06/2018 09:29 AM, Christian Boltz wrote:
>> Hello,
>>
>> Am Montag, 5. Februar 2018, 22:13:19 CET schrieb Marco d'Itri:
>>> On Feb 05, Jamie Strandboge <jamie at canonical.com> wrote:
>>>> It continues to be a tricky problem. I think mostly we really need
>>>> to
>>>> make sure the binary policy is on the same partition as the text
>>>> policy. If we start thinking of it as binary policy, perhaps we can
>>>> instead put it in /lib. Eg, /lib/apparmor/policy. FHS adherents will
>>>> argue that this isn't the right place, but /etc is no better and the
>>>> FHS doesn't handle early boot well at all (this is presumably why
>>>> system uses /lib/systemd/system).
>>>
>>> If the binary policy may change when /etc is changed then the only
>>> options are /etc/ and /var/.
>>> Please please please do not break this: /lib (which nowadays is
>>> a symlink to /usr/lib) is immutable and can be shared between systems.
>>
>> Agreed, but let me mix in another idea/discussion we [1] had at FOSDEM:
>>
>> What about using an override directory - /usr/something for cache files 
>> _shipped in the packages_ (for unmodified profiles), and /var/something 
>> to handle the cache for modified profiles.
>>
>> I know this means some additional code in the parser, but would make 
>> packaging a pre-built cache much easier when it comes to avoiding 
>> *.rpmnew files etc.
>>
>> The way this could work would be:
>>
>> a) for reading the cache / loading a profile
>> - check if there's a valid cache file in /var/something and use it
>> - otherwise check if there's a valid cache file in /usr/something and 
>>   use it
>> - otherwise write the cache file to /var/something
>>
>> b) for writing the cache
>> - write to /var/something by default
>> - write to /usr/something only when using 
>>       apparmor_parser --cache-loc /usr/something
>>
>> c) for --purge-cache
>> - only delete files in /var/something (except if --cache-loc is used)
> 
> and this already exists (its not ready to land quite yet) in
> https://gitlab.com/jjohansen/apparmor/tree/multicache
> 
> it supports overlay caches, where you can provide a list of cache
> locations that are to be searched in order
> 
> --cache-loc=/A,/B,/C

How do I use the cache location of /var/lib/larry,moe,curly with an
overlay using the relative path shemp/? Should we just accept multiple,
ordered --cache-loc's instead?

This is the only question my checked out mind could come up with on a
Friday afternoon.

Tyler

> 
> with the first cache location (/A) being also the writeable location
> (assuming --write-cache is enabled).
> 
> In addition to allowing a set of overlay cache directories it also
> provides for multiple caches. One set per kernel feature set. So each
> kernel now has its own binary cache that can be pre built and
> rebooting into different kernels won't clear the cache.
> 
> This helps solve some of the problems but not all of them. All of the
> binary locations have to be available at early boot if we are going to
> have systemd load the cache early. And we have different communities
> with different requirements.
> 
> - We have read only images, with read only text and binary policy
> - We have people wanting to empty out /etc/ (no policy or cache)
> - we have people who want to put the early policy in the initrd/initramfs
> - We have people who are doing multiple policy and cache locations
> ...
> 
> Taking the above overlay approach and applying it to text policy we
> could allow for local modification that override shipped distro policy
> (in fact something like this is going to be needed for read only
> images, but you loose the ability to detect collisions of policy
> updates with local changes that dpkg and rpm give us .dokg-new/old/bak
> and .rpmnew/save) with the modifications and cache being able to be
> placed in complimentary locations.
> 
> In the end we are just going to have to come up with some upstream
> defaults that are easy for down streams to change, because we are not
> going to be able to please everyone.
> 
> The current idea bouncing around is to have a policy.conf file, which
> init and similar functions can use to determine policy and
> corresponding cache locations.
> 
> Bearing in mind that syntax etc haven't been determined, it would be
> something like
> 
> 
> [system policy] #notice the overlay policy and cache locations
> 	location=/var/libapparmor/,/etc/apparmor.d/
> 	cache-loc=/var/cache/apparmor,/etc/apparmor.d/cache
> 	options=--write-cache
> 
> [click policy]
> 	location=/var/lib/apparmor/
> 	cache-loc=/var/cache/apparmor
> 	options=--write-cache -O no-expr-simplify
> 
> [snap policy]
> 	location=/var/lib/snapd/profiles
> 	cachel-loc=/var/cache/apparmor
> 	options=--write-cache
> 
> [lxd policy]
> 	load-only
> 	managed-by: lxd
> 	cache-loc=/var/lib/lxd/apparmor/cache
> 


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