Proposing SELinux support in strace
rmetrich at redhat.com
Wed Feb 17 07:43:15 UTC 2021
So far I modified the code to check for the mount namespace used by the
tracee and strace and avoid doing any selinux context resolution upon
having non-matching namespaces.
I've also fixed the relative pathname issue by storing the dirfd and
checking against it if needed.
However this also doesn't work all the time, in particular when the
relative path is beyond the rootdir of the process (because ../../../ on
"/" returns "/").
So there are clearly limitations I cannot handle easily for now.
I will continue working on this after Devconf, in particular writing new
I'm already using this patch when debugging Red Hat customers issues and
so far it was really of great help already.
On 2/17/21 1:10 AM, Dmitry V. Levin wrote:
> On Thu, Jan 21, 2021 at 01:00:08PM +0100, Renaud Métrich wrote:
>> Right, it's broken, that cannot work all the time...
> Right, what do you suggest to do with that brokenness?
>> On 1/20/21 12:13 AM, Dmitry V. Levin wrote:
>>> On Sat, Nov 21, 2020 at 09:08:45PM +0100, Renaud Métrich wrote:
>>>>> By the way, is it correct to hook selinux_getfilecon into printpathn?
>>>> I agree it's kind of a "hack", using "printpathn" is just the simplest
>>>> way to get SELinux contexts when a path is used.
>>> How likely for the result to be correct if strace and the tracee have
>>> different root fs? Also, would the result be correct when the path printed
>>> by printpathn is not an absolute file name?
>>> From implementation point of view, looks like you hooked into printpathn
>>> in a way that a non-nul-terminated string may be passed to selinux_getfilecon.
>>>>> Also, do you want to display secontext associated with file descriptors?
>>>> Thanks to hooking "printpathn", the context for file descriptors will
>>>> also be printed, e.g.:
>>>> [unconfined_t] ... read(3</usr/lib64/libselinux.so.1> [lib_t],
>>>> 832) = 832 <0.000015>
>>>> That's why hooking "printpathn" is great here.
>>> You've explicitly hooked into printfd_pid to achieve that, haven't you?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 840 bytes
Desc: OpenPGP digital signature
More information about the Strace-devel