[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