Proposing SELinux support in strace
Renaud Métrich
rmetrich at redhat.com
Fri Mar 5 14:04:47 UTC 2021
Dear all,
I reworked the code and created some unit tests. (PR
https://github.com/strace/strace/pull/121)
Unfortunately I'm not able to build correctly under the CI for several
reasons:
- 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
e.g.
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/libselinux.so 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.
Renaud
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/libselinux.so.1> [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: <http://lists.strace.io/pipermail/strace-devel/attachments/20210305/6e076656/attachment.bin>
More information about the Strace-devel
mailing list