Proposing SELinux support in strace

[Renaud Métrich]

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/20210217/10d09a08/attachment.bin>