[apparmor] Apparmor : Common Query

[Seth Arnold]

On Thu, Sep 22, 2022 at 02:48:43PM -0400, Murali Selvaraj wrote:
> *foo.sh*
> #!/bin/sh
> if condition
>    /bin/sh script_1.sh
> fi
> /bin/sh script_2.sh
> while [ condition ]
> do
>    if [ condition ]
>         /bin/sh script_3.sh
>    else
>         /bin/sh script_4.sh
>    fi
> done
> 
> *Queries:*
> 
> -  If we create a separate profile for each script (for instance,
> script1_1.sh)  and consolidate to one profile for foo.sh
> -  However, we will try to perform/exercise all possible test cases to
> execute all code paths while running in complain mode to gather logs
>    for preparing the profiles.
> -  Do we have any recommendations to prepare an Apparmor profile for Linux
> scripts?

Does your actual software use /bin/sh foo.sh intentionally? Why? executing
foo.sh via direct execution will make domain transitions *vastly* easier.
This is worth re-writing your software to directly execute your other
scripts rather than executing your interpreter to execute the scripts.

> *Question 2:*
> 
> - In my embedded system most of the rootfs files are in READ-ONLY except a
> few directory,files are READ-WRITE (for instance, non-volatile partitions
> and so on).
> - All libraries in my device rootfs are located in READ-ONLY folders (
> /lib/, /usr/lib and so on).
> - While preparing profiles for my applications, I am adding each entry of
> the library as per the application access.
> 
>   /lib/** mr,
>   /usr/lib/** mr,
> 
> - Since all libraries are in READ-ONLY, if we allow all libraries (with
> wild-card) any possible security leak?

Yes, though it's hard to say for sure. It's possible to mount new
filesystems on top of read-only mounts, or on top of read-only files and
directories.

If you use the wildcard, it might be easier to drop in a malicious payload
without affecting the rest of the system.

> - Do we still have command-line injection possible to the library too? I am
> trying to understand here, how do we affect security leaks if we allow all
> libraries (since they are in READ-ONLY directory).

I'm not entirely sure how to approach this question. Any library that
uses system(3) or popen(3) (or implements their own similar functionaliy)
could have command-line injection problems. AppArmor policies could
prevent the shell from executing at all. AppArmor policies could restrict
which executables the shell could start, which files can be accessed,
which signals could be sent, etc.

I hope this helps.

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20220922/7b0627bb/attachment.sig>