Proposing SELinux support in strace

Renaud Métrich rmetrich at
Fri Mar 5 14:04:47 UTC 2021

Dear all,

I reworked the code and created some unit tests. (PR

Unfortunately I'm not able to build correctly under the CI for several 

- code coverage breaks because the CI system has no SELinux labels, 
hence the new code is not covered

- compilation with -m32 fails because there is no suitable selinux 
library for 32bits apparently


2021-03-05T13:17:54.4436301Z gcc-10 -Wall -Wempty-body -Wformat-security 
-Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self -Wlogical-op 
-Wmissing-parameter-type -Wnested-externs -Wold-style-declaration 
-Wold-style-definition -Woverride-init -Wsign-compare -Wtype-limits 
-Wwrite-strings -Werror -g -O2 -DMPERS_IS_m32 -m32  -o chmod--secontext 
chmod--secontext.o -lselinux libtests.a
2021-03-05T13:17:54.4515828Z /usr/bin/ld: skipping incompatible 
/usr/lib/x86_64-linux-gnu/libselinux.a when searching for -lselinux
2021-03-05T13:17:54.4517295Z /usr/bin/ld: cannot find -lselinux
2021-03-05T13:17:54.4518771Z /usr/bin/ld: skipping incompatible 
/usr/lib/x86_64-linux-gnu/ when searching for -lselinux
2021-03-05T13:17:54.4520200Z /usr/bin/ld: skipping incompatible 
/usr/lib/x86_64-linux-gnu/libselinux.a when searching for -lselinux
2021-03-05T13:17:54.4521300Z /usr/bin/ld: cannot find -lselinux
2021-03-05T13:17:54.4522032Z collect2: error: ld returned 1 exit status

I have no idea what needs to be done to fix this. All I see is configure 
enables selinux support because the 64bit lib is installed, but 
apparently not the 32bit one.


On 2/17/21 8:43 AM, Renaud Métrich wrote:
> 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 test cases.
> I'm already using this patch when debugging Red Hat customers issues 
> and so far it was really of great help already.
> Renaud.
> 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/> [lib_t],
>>>>> "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\207\0\0\0\0\0\0"..., 
>>>>> 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...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the Strace-devel mailing list