Arjun Shankar <arjun@redhat.com> writes:
>> + else
>> + /* Program is AT_SECURE but the only source of program
>> + name is argv[0], which is not secure, so we do not
>> + match any name-based filter. */
>> + goto skip_due_to_filter;
>> + break;
>> + default:
>> + break;
>
> There's an argument to be made that skipping here is the better
> choice. When can this happen? I expect the options are: 1. corruption,
> and 2. newer file version being read by an older loader? Still, it's
> hard for me to say if applying the tunable is better here, or skipping
> it.
I added an explicit flag for *_FILTER_NONE, and had that case "break;".
The default case now only matches unknown filters, and I agree being
pessimistic about this is right.
In v8 the default case here was used for "no filter specified".
>> + if (colon - line - 1 == 4 && memcmp ("proc", line + 1, 4) == 0)
>> + {
>> + /* Consider this example: [proc:foo] ..." */
>> + /* We allocate 4 bytes, [0] through [3]. */
>> + filter_string = (char *) malloc (right_bracket - colon);
>
> This malloc result should be checked.
I included xmalloc.h to handle these, then forgot to use it. Changed to
xmalloc(), two places (one is in 1/5)
>> @@ -117,6 +205,24 @@ add_tunable (char *line, const char *filename, int lineno)
>> top = TOP_DENY;
>> line += 15;
>> }
>> + else if (strncmp (line, "onlysecure ", 10) == 0)
>
> Should be a length of 11 for this one.
Fixed.