From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id A28F93858426 for ; Fri, 6 Oct 2023 19:14:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A28F93858426 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-pl1-x630.google.com with SMTP id d9443c01a7336-1c6219307b2so18469405ad.1 for ; Fri, 06 Oct 2023 12:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1696619683; x=1697224483; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=94hKHP4Qi9seDHBP5iIPwJwUXRBKaw7jcubF4tbftS8=; b=TQ2dJGgMaewSaOJm4HyLPU6IVOZyrRvYU4aN3PBYenb0m2KNzekCLNS45fgjZOs299 KtUTyUW/kwDsCrtdm+9LQEToGQ0HIottDIsvUAnjeIa6bIhXArawkZK5If7ZFx82VYyk RaDkhourzfYxmvF55R3CNlZ+IP42pWnZ09Ohqdpf7qx3+wGMvoRi0LRZBauUSII4yn7P ifdGNZMKm2ue2X00SkGLlFlvus2C6BVGpUR0edSTcYwQgNJ++e+oJ6fRRhDZBFMVI2LQ jMy7urRjUM0mckjcVN1VQzdtqKsDpM39jtM0ZEjDm3+c2Gb7jZQ63OUkh25jSJDC3o7R 0oiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696619683; x=1697224483; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=94hKHP4Qi9seDHBP5iIPwJwUXRBKaw7jcubF4tbftS8=; b=rV1dXDSI/GS779xcY19wpwgjlA65BMXxJUcUSNHHhRHZSmS1ATJF+r/5AzlmPp9ZxV wpoj2558MjctW7g/UcRoAAbuEcVnBPSxccNdGIPwUU7NZkSymvV0VX/ioqwgnXajTIxp ms1RuGrLIiCDqxpDfCqVCf8wg0crQf3UHndXdrIhD9jELpCqfSdT6/xLjz62zVSkg8Fw 3bV2mDhuuJIm2zDD/3pyGWYDIfKIe5OI0LS92fqV9YtIRses8kHk5mIwdlWymB+VzQVN jr5Z5AjGzLdG3+YlCRtg7QdLivkXICet7AoH+qfExxAiIaEvTTBY4kdFPWGQQdPOLuiH 7dyg== X-Gm-Message-State: AOJu0Yz79i8F2WI5Tq58utyxKAI/QufL1rXLZ7nV1g/L3uSoy07y6jy6 wD6Y68ZX/O0Pp/9vEbHTqwvJhToPRXiUDxEb4iGM7g== X-Google-Smtp-Source: AGHT+IH7ypFANvh1/1BjrfeZcZAW2pB5c9B0ZIdygNgSYeZGADBzTc9aWUEi6kXwPLBgtLw/jBestg== X-Received: by 2002:a17:903:1207:b0:1c0:bcbc:d64 with SMTP id l7-20020a170903120700b001c0bcbc0d64mr10370722plh.51.1696619683056; Fri, 06 Oct 2023 12:14:43 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c1:feaf:9e9:3fff:94f8:9e64? ([2804:1b3:a7c1:feaf:9e9:3fff:94f8:9e64]) by smtp.gmail.com with ESMTPSA id l9-20020a170902d34900b001b9be3b94d3sm4261967plk.140.2023.10.06.12.14.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Oct 2023 12:14:42 -0700 (PDT) Message-ID: Date: Fri, 6 Oct 2023 16:14:40 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: RFC: system-wide default tunables Content-Language: en-US To: DJ Delorie Cc: libc-alpha@sourceware.org References: From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 06/10/23 15:29, DJ Delorie wrote: > Adhemerval Zanella Netto writes: >> The idea sounds ok, but adding on ld.so.cache means it would not work >> for static. I don't think this is really an issue, static PIE is really >> tricky because self-relocation happens after tunable (because tunables >> itself might change ifunc selection); and trying to add support for >> static PIE would require a lot of messy refactoring (all ld.so.cache >> loading would need to be annotated hidden, no external function calling, >> even mem* ones; etc.). > > The idea behind using this is that admins are used to running ldconfig > and managing ld.so.cache, so there would be nothing new to learn. The > cache already has some hwcaps-related info in it, too, for selecting > suitable libraries. The hwcap-related are still used for library selection, the original intention of the ld.so.cache. What I am afraid is ld.so.cache start to being an umbrella for different and unrelated settings. > >>> Ideas: >>> >>> * Specify some file or files in /etc that contain tunables settings. >>> Follow the ld.so.conf patterns, allow subdirectories, etc. >>> >>> * Store tunables info in /etc/ld.so.cache in a new slot at the end, >>> with a new enum for the chunk. This way older glibc will just >>> ignore it. Parsing and storing will be done via ldconfig. >> >> It means that we will have to always load the ld.so.cache, not only when >> we will actually have to load an ET_DYN . It should be ok, but runtimes >> that usually only link against libc.so (like rust) will have additional >> overhead on startup. > > We don't have to "load" it just map it and read the aux data at the end. > But, yeah. By 'load' I man mmap the ld.so.cache, which still adds extra commit charge. > >> We also have DF_1_NODEFLIB to inhibit loader cache search, should we add >> another flag to inhibit the global tunables? It does not make sense to >> set per-library, but it still might be useful to set on ET_EXEC. > > If there were a system-wide tunable that caused improper action, it > wouldn't be a "tunable" it would be a "stoppable". If a single program > was incompatible with system-wide tunables, it would need the environmen > variable set to tune them for the specific program. It is not improper action that I worried, but security and performance implications. For instance, the malloc tunables change performance depending of the workload; a system-wide tunable might not the best option for all programs. The DF_ is just a shortcut to avoid the need to know which tunables are set system-wide (assuming that the environment variables has precedence over the system-wide). But I am assuming that system-wide has preference over user-defined, which does not seems the case for your proposal. > >> So I am not fully sure adding the global tunable setting on ld.so.cache is >> the correct approach. However, adding on an external file will add >> another open/mmap/close on each program; plus the extra mmap. > > Yup. And worst case, those apps that don't get the tunable... act like > they do now, with no system-wide tunables. > > If the settings were mandatory, I'd worry more. I think what is not clear is if the idea is to mimic the 'security_level' of tunable (which I intend to remove), in a way that we might have tunable that might overridden and/or disabled by the process (through the envvar). > >>> * Values in ld.so.cache will be parsed but not range checked; that's >>> dependent on what the glibc app expects. >> >> Importing the range information on tunable definition is straightforward, > > Unless it differs between applications. Or if the cache were generated > with one version of glibc and the application runs with a different > version. But in this case, and invalid/unknown value should be ignored if the program is using a different glibc version. Setting an invalid/unknown tunable still make little sense to me, it means that it will always be ignored by some target if you are running different glibc with different tunable setting support. And I don't see why we should not make it explicit for the administrator. Maybe the best way is to make the range/key check as default and add an option to force to set invalid values. > >> so I think we should add the range check on ldconfig ld.so.cache setup. >> There is no error checking on env var tunable, invalid values are just >> ignored without any user feedback. Since we will do pre-processing, >> I think it would be valuable to at least show any possible invalid range, >> specially because this is a administration setting. > > I see no problem with validating at cache time, but I don't want to skip > range checking at run time. Doing so leads to security bugs. I agree, and I was not suggesting otherwise. > >>> * read those, do range checking, and call callbacks at runtime >>> >>> * To speed processing, encode a hash for each tunable name, both in >>> glibc's table (which is built at glibc build time) and in >>> /etc/ld.so.cache. Comparing the hash typically fails but avoids a >>> string compare. Matching hashes are followed by a string compare to >>> verify. The hash need not be crypographically secure. > >> Do we really need this optimization? Internally, the tunables are already >> accessed through a enum, > > That enum might change from version to version. We're already seeing > enum-related issues with RHEL upgrades. Yes, Carlos has brought the awk sorting problem. I think this is fixable (maybe porting the tunables generation to python, run the sysdeps search in a predictable way, set enum value based on tunable ordering) and we can add test to check if tunable enum changes over releases. I still think this is simpler than data structure your are proposing, and with less performance issues. But I don't have a strong preference. > >>> * I'm not going to try to add some "syntax" to specify if a tunable is >>> overridable or not; this is a simple default-only change. >> >> How should we handle the envvar GLIBC_TUNABLEs in the presence of a system-wide >> tunable? > > The variable overrides the cache. Right. Do we allow security opt-in option as well? I am asking because in this case, it is expected that the system-wide should not be overridden. > >>> * Tunables set by these defaults will not be disabled for setuid >>> programs; it's assumed they're a "trusted source". >> >> This seems reasonable, and with this rationale should we add an option >> to allow some tunable to be disabled or overriden? I take this is an extra >> complexity that we should not pursuit. > > Agreed; we want a simple system. > >> Another possible feature that comes from the tunable discussion is >> whether make sense to add a per-process tunables. > > Er, isn't that the environment variable? > It is a easier way to configure per-process tunable, it avoid messing with FS that either are mounted RO or do not allow adding wrappers to setup GLIBC_TUNABLES. Also, my idea is to just remove the tunable setting for setuid/setguid; so per-process is a way to setup specific rules for security sensitive processes (assuming that we will support non-overriden security tunables).