On Mon, Apr 05, 2021 at 01:09:02AM +0530, Murali Selvaraj wrote: > -> 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?
Hello Murali,
/proc/pid/maps only reflects libraries that are currently in use. It's
possible for applications to use dlopen(3) to dynamically load libraries
at runtime (think "plugins") -- and probably some applications do
something very similar for dynamically loaded libraries but do it
themselves rather than using dlopen(3).
So /proc/pid/maps is good enough for most applications but it is not
comprehensive in the general case.
> -> 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 could use filesystem auditing rules or syscall auditing rules with
auditd, or you could use ebpf tools like opensnoop from the iovisor
project to catch file and directory opens, reads, writes. There's a lot of
systemcalls that do file IO, though, and it'd be easy to overlook one that
your application uses.
You could use perf to enumerate all the syscalls that your application
uses in its test suite, and then audit all the file-related syscalls.
> -> 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 don't understand this question.
A confined process needs to have AppArmor rules to allow whatever it is
that you actually want to allow.
> Can you please explain the difference for the below entries in the
> apparmor profile?
>
> /tmp/lock_file rw,
> /tmp/lock_file rwc,
'c' is how the kernel portion of AppArmor reports a file creation attempt.
'c' is not accepted in the userspace portion of AppArmor policies, so your
second rule will fail to compile:
$ echo "profile p { /a c, }" | apparmor_parser -Qd
AppArmor parser error, in stdin line 1: syntax error, unexpected TOK_ID,
expecting TOK_MODE
> /tmp/test.css ww,
> /tmp/test.css w
> /tmp/initialized rww,
> /tmp/initialized rw,
The second 'w' is redundant and doesn't do anything. The parser accepts
this without error, though:
$ echo "profile p { /a ww, }" | apparmor_parser -Qd
----- Debugging built structures -----
Name: p
Profile Mode: Enforce
--- Entries ---
Mode: wa:wa Name: (/a)
> /tmp/driver krw,
> /tmp/driver rw,
The version with 'k' lets your application call flock(2) on the file
/tmp/driver.
> 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?
This depends on how the application was originally started and how you'll
restart it, as well as the application policy that you've written. If the
supervisor that you're using to start the application is responsible for
restarting the application, it'll probably go fine. If a different
mechanism is being used to restart the application, it might not.
> 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?
>
> 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?
For this specific entry two possibilities make sense:
/tmp/test w,
owner /tmp/test w,
The application may need other permissions later; AppArmor can't know when
the file is created if the application will read from it, lock it, execute
it, etc. It won't know those things until the application actually issues
syscalls for that.
Thanks
signature.asc
Description: PGP signature
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
