I’m seeing the following denial after an ftruncate call:
avc: denied { open } for name="test" dev="dm-2" ino=8909 scontext=u:r:isolated_app:s0:c512,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=file permissive=0
The isolated_app process has been passed the open file descriptor and it has the write permission:
Truncating an open file should only require the write permission. The following commit introduced this functionality:
commit 95dbf739313f09c8d859bde1373bc264ef979337
Author: Eric Paris <eparis@xxxxxxxxxx>
Date: Wed Apr 4 13:45:34 2012 -0400
SELinux: check OPEN on truncate calls
In RH BZ 578841 we realized that the SELinux sandbox program was allowed to
truncate files outside of the sandbox. The reason is because sandbox
confinement is determined almost entirely by the 'open' permission. The idea
was that if the sandbox was unable to open() files it would be unable to do
harm to those files. This turns out to be false in light of syscalls like
truncate() and chmod() which don't require a previous open() call. I looked
at the syscalls that did not have an associated 'open' check and found that
truncate(), did not have a seperate permission and even if it did have a
separate permission such a permission owuld be inadequate for use by
sandbox (since it owuld have to be granted so liberally as to be useless).
This patch checks the OPEN permission on truncate. I think a better solution
for sandbox is a whole new permission, but at least this fixes what we have
today.
Signed-off-by: Eric Paris <eparis@xxxxxxxxxx>
Perhaps this should distinguish between truncate and ftruncate calls?
_______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
