On 05/06/2017 12:54 AM, Ian Pilcher wrote:
I am trying to write an SELinux policy to confine a simple service that
I have written in Python, and I'm trying to decide whether to allow or
dontaudit various denials.
To start, I've reduced my service to the simplest case:
#!/usr/bin/python
import sys
sys.exit()
Running this program in a confined domain generated the following
denial:
avc: denied { read } for pid=2024 comm="denatc" name="meminfo"
dev="proc" ino=4026532028 scontext=system_u:system_r:denatc_t:s0
tcontext=system_u:object_r:proc_t:s0 tclass=file
The program does continue on and exit cleanly, so it doesn't seem to
strictly require the access.
Does anyone know why Python is trying to access this file, or what
functionality I might be missing if I don't allow the access?
Usually tools read /proc/meminfo to figure out how much memory is
available on the system and then to make some assumption about how much
memory they can use. A tool might allocate a memory buffer as X% of
total memory on the system. (This is a bad assumption, since cgroups
could alter the total amount of memory availabel to the process, but
/proc/meminfo does not reflect the amount of memory available in the
cgroup). The code that looks at /proc/meminfo might be builtin to
libc, I would figure that whatever is trying to read /proc/meminfo
expects to fail in certain situations, so it falls back to an alternate
code path. This is most likely what you are seeing.
In most situations reading /proc/meminfo would not be considered a
security risk, especially considering in the case of Cgroups the kernel
will LIE. :^)
