On 4/4/21 12:39 PM, Murali Selvaraj wrote: > Hi John/Seth, > > Thanks John/Seth for your detailed information. > > Can you please clarify the below queries. > > Query 1: > > -> From the aa-log-prof, we are able to generate an apparmor profile > for the required process. In order to confirm the profile(by > theoretically) > if we compare cat /proc/<pid>/maps | grep -i lib this output will > it be sufficient or any possibility of the libraries may > not be in this entry cat /proc/<pid>/maps? > /proc/<pid>/maps will only show libraries that have been mmapped. If new libraries are dynamically loaded they could indeed be missing
> -> Like a library, do we have any other way to find the list of > configuration, temporary files using by process can be identified > by simple tools or from any /proc entries like above? This is just > to confirm about our profile. > you can use ldd to find most library dependencies. Again it is possible that this will miss things if they are dynamically loaded. We don't have any tools atm that do binary analysis of a program to try and discover resources that are accessed. But you could use tools like gcov and program test suits to discover how much of the program has been exercised. > Query 2: > > -> For example, one of my process is running in "non-root" owner which > has read/write access to /proc/<test>/<test_2>/ > While generate profile for this process, Do I need to add this > entry /proc/<test>/<test_2>/* rw, Or without adding this entry > will it able to do read/write operation /proc/<test>/<test_2>/? > I'm sorry I am not sure I follow what you are asking. Assuming your running process is confined by an apparmor profile then that profile will require rules to access proc entries. What entries the task can access will depend on the rules that the profile has, so you very well might need to add a rule. In addition. In apparmor /proc/<test>/<test_2>/ r, would only give access to the directory listing of /proc/<test>/<test_2>/ not any of the files or directories under it. So adding /proc/<test>/<test_2>/* rw, might indeed be needed. > Query 3: > > Can you please explain the difference for the below entries in the > apparmor profile? > > /tmp/lock_file rw, > /tmp/lock_file rwc, > c as a permission in policy is not supported, nor will it ever be supported because it is to easy to confuse/mix it up with cx where the c in cx means child. The ability to specify create separate from rw is coming, its just not available yet. so "/tmp/lock_file rwc," is invalid and will result in an error similar to AppArmor parser error at line 1: syntax error, unexpected TOK_ID, expecting TOK_MODE yes the error message needs to be improved > /tmp/test.css ww, > /tmp/test.css w > no difference > /tmp/initialized rww, > /tmp/initialized rw, > no difference > /tmp/driver krw, > /tmp/driver rw, > > /tmp/driver krw, will allow taking shared and exclusive locks on the file in addition to allowing read and write. > > Query 4: > > By default, while device boots apparmor profiles are loaded to Kernel > and the corresponding process read from the profile during the process > execution, > -> As per our code, the process kills/crashes by unknown reason; we > have a mechanism to restart by itself. > In that case, during the process restart, will it start as per > profile or without profile? That will depend on policy, and who is restarting the processes. AppArmor profile attachment is determined by the confinement of the task that execs the process. If the task relaunching the process a profile rule that determines ix (inherit) should be used then your relaunched process would use the same profile. If the task's profile has a rule that determines px should be used then the a search for the best matching profile for the exec program is done, and that would be used. If the task that is relaunching the process is unconfined, that means it is the profile attachment is done via a pix rule. So the set of loaded profiles will be searched for a best match, and if no match is found the relaunched program will inherit the lanching tasks confinement (in this case unconfined). > > > Query 5: > > I would like to understand the reason for below DENIED logs, what does > it really expect? > Do I need to add the entry like /tmp/test c or /tmp/test rw or > /tmp/test rwk? Pls share the difference for each mentioned > possibility? > /tmp/test c, invalid /tmo/test rw, allow read, write, create, trunc etc on the /tmp/test file (not dir) /tmp/test rwk, Same as above but also allow exclusive mandatory locks on the file. > 2021 Apr 04 17:35:05 admin kernel: audit: type=1400 > audit(1617557705.711:207): apparmor="DENIED" operation="mknod" > profile="example" name="/tmp/test" pid=11410 comm="application" > requested_mask="c" denied_mask="c" fsuid=0 ouid=0 > > What is really this log expecting? > To remove the above denial you need /tmp/test w, The w permission really covers more than just write. It covers write, append, create, truncate, meta write. Its simple but is not terribly fine grained. When the extended permission work lands you will have the option of being more fine grained, separating each of those out. Eg. /tmp/test (create,append), but that is NOT available yet. > Thanks > Murali.S > -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
