[File] [PATCH] Fix seccomp rules for executing decompressor on glibc
Christos Zoulas
christos at zoulas.com
Thu Sep 15 16:56:26 UTC 2022
On 2022-09-15 10:57 am, Michał Górny wrote:
> On Thu, 2022-09-15 at 10:27 -0400, Christos Zoulas wrote:
>> On 2022-09-15 4:10 am, Michał Górny wrote:
>> > Add ALLOW_RULE for all the syscalls used by glibc on my system to spawn
>> > the decompressor. With them present, `file -z ...` starts working
>> > again
>> > when not using external libraries, at least on amd64. Other
>> > architectures may need more syscalls.
>>
>> Yes, I know. The reason I have not done this already is because once
>> we
>> allow clone and execve there is not much point in sandboxing... I
>> guess
>> we can modify -S to add those syscalls instead and that is better than
>> completely disabling sandboxing... What do you think?
>>
>
> Yeah, I feel like seccomp becomes pretty much useless at this point.
> That said, I don't really understand why file(1) would need it
> in the first place.
>
> Perhaps another option would be to just disable spawning external
> compressors when sandboxing is enabled. I don't think it's critical,
> my
> main concern is that the output like:
>
> $ file -z t.tar.lz
> t.tar.lz: Bad system call
>
> is quite confusing.
Yup, just did that.
christos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <https://mailman.astron.com/pipermail/file/attachments/20220915/485f17af/attachment.asc>
More information about the File
mailing list