[PATCH v5 4/4] Add system-wide tunables: Filters

[DJ Delorie]

Florian Weimer <fweimer@redhat.com> writes:
> Ideally this would be consolidated with the l_origin computation for the
> main map. The logic seems a bit backwards to me.

I looked at that, and it calls readlink(/proc/self/exe) and immediately
discards the basename portion, making it useless for this.

> I think we need two matching modes here:
>
> * The path is deemed trusted by the system administrator.  The tunable
>   is used for all binaries (including when __libc_enable_secure is
>   active).
>
> * The path is not trusted.  The tunable is not used in AT_SECURE mode.
>
> All argv[0] comparisons are not trusted (not used for AT_SECURE mode).

Let me see if I understand:

1. if AT_SECURE is set and /proc/self/exe isn't readable, we ignore
   argv[0] and just don't match any [proc] filters

2. If AT_SECURE is not set, or /proc/self/exe is readable, we allow
   [proc] matches.

>> diff --git a/elf/tst-tunconf1.root/etc/tunables.conf b/elf/tst-tunconf1.root/etc/tunables.conf
>> new file mode 100644
>> index 0000000000..3c7b33c399
>> --- /dev/null
>> +++ b/elf/tst-tunconf1.root/etc/tunables.conf
>> @@ -0,0 +1,6 @@
>> +glibc.malloc.tcache_max=6
>> +glibc.malloc.tcache_count=3
>> +[proc:/bin/ls]
>> +glibc.malloc.tcache_max=7
>> +[proc:tst-tunconf1]
>> +glibc.malloc.tcache_max=4
>
> I'm still a bit on the fence regarding the separate tunables.conf
> file.  I think deployment (through tools like Ansible) is easier if
> integrated with the existing ld.so.conf framework.

The argument against this, IIRC, was a desire to not break any existing
documentation or sysadmin training for /etc/ld.so.conf.  Changing its
syntax means decades of knowledge and scripting become obsolete.

> I would recommend a more keyword-oriented syntax that allows future
> introduction of additional directives.  So perhaps something like:
>
>   match-executable-path "/usr/bin/ls"
>   set-tunable glibc.malloc.tcache_max=7
>
> We should have a proper way for quoting strings from the beginning.

I can write an entire language parser and bytecode interpreter for this
if we want to go crazy with the syntax, but I'd rather not...

Relying on punctuation and simplicity means fewer string operations that
might become CVE's in the future.

The [section] syntax is common in config files.