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
signature.asc
Description: PGP signature
