Hello, > On Thu, Oct 2, 2014 at 10:48 AM, Tom Rivers wrote:
> > On 10/2/2014 09:58, Rahul Sundaram wrote: > > > > I didn't address it because it was not really relevant either. The > > > impetus > > > is > > > merely the backstory. > > > > > On the contrary, the rationale for your proposed change is very relevant. > > Sure but the rationale isn't just security as I have explained earlier. Do > read the links and other mails fully. OK, then; care to explicitly list the advantages you expect to see from such a switch, and why they outweigh the disadvantages and the migration costs? AFAICS: The expected security improvement is essentially nonexistent. In the current case of importing functions from the environment (and we could have a looong philosophical conversation about whether this is a vulnerability in bash or in its callers, where the likely outcome is “not a vulnerability in bash but by far easiest to fix in bash”), I expect/hope that the environment variable channel has been audited to death. Outside of this case, the shell is, by its nature, a programming language interpreter, and it doesn’t do any kind of privilege escalation: if you feed it arbitrary input, you get to do arbitrary things, but no more than you could do without the shell. The shell really should be transparent/fairly irrelevant to security (which is also why so little attention has been paid to it).¹ And as for any measure of performance, by the very fact that the scripts are written in shell we already know that the scripts are not performance-critical, or at least have not been worth optimizing for performance. So, it seems to me, all we are left with is a bit of performance/space optimization just because we can, at the very real cost of breaking existing scripts, both within the distribution and on users’s systems. Mirek ¹ The exceptions being attacks through other programs that do escalate privileges and call shell with untrusted data (as in shellshock), and attacks through the shared environment (in this case, mainly filesystem contents and various small/constrainted states like the PID space).
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
