[apparmor] Apparmor on Embedded devies.

[John Johansen]

On 3/30/21 11:11 AM, Murali Selvaraj wrote:
> Hi All,
> 
> We are planning to use "Apparmor profiles" as part of Security reasons.
> -> Assume, we have finalized a profile for a certain process after
> experiment in our setup/QA validation.
> -> Next day, there is a possibility of any code merging where this
> entry won't be available in the existing (2) profile as we freeze the
> profile.
> -> As we know that code has been merged/updated continuously (day to
> day) on the particular process, Do we have any mechanism to ensure how
> the Apparmor profile  aligns with the latest process/image?

I am sure I understand the question. Do you mean is there a way to
ensure the profile is updated for any given change set or do you mean
is there a way to tie a profile to a specific application revision?

There is no automatic method to ensure the profile is updated for a set
of application changes (day to day revisions). Incremental revisions
to the profile can be made by inspection the code changes or running
the application against the profile in complain mode and then updating
it for any new allowed log entries.

If you are asking if there is asking is there a way to tie a specific
profile to a specific application revision, then you can use the
xattr attachment conditional.

To do this you need to set an xattr that apparmor can compare against.
The value you use is up to you but a good idea would be using a
crytographics hash of the application. You then provide the hash
as part of the attachment specification. Eg

profile example1 /bin/example xattrs(security.apparmor="\xd2\x32\x4f\x8d\xb1\x73\x74\x29\x62\x34\x3a\x30\xa9\x9a\xa8\x57\x8b\x22\xd9\x78") {
  ...
}

profile example2 /bin/example xattrs(security.apparmor="\x94\x5a\x7f\xf0\xb6\xd2\xa4\xbf\xbe\x58\x99\xff\xf9\x6b\x15\x77\xdf\x48\x7f\x28") {
  ...
}

The profile name has to be different (at least if being loaded into
the kernel at the same time) hence example1 and example2 but the
executable path for attachment can be the same and then which profile
is attached is then based an the xattr value.


Note: apparmor will not check that the hash is valid to the application,
for integrity checks apparmor combines with IMA and IMA is used to
check the integrity of the file.


> -> What is your thought on using embedded device head-set?

I am sorry I don't understand the question. If you mean using
apparmor on embedded device. You can do it. Generally I would
suggest going with precompiled policy and a read only image.

This keeps the policy from being compiled on the device and
makes the load a lot quicker and the resource requirements a
lot less (the compile takes a lot of resources).

> -> Please share the detailed inputs.
> 
> Thanks
> Murali.S
>