> Assume you have a bad program1 and you write your tame(2)-ed program2 that > disallows execution of program1. But you also have to use my un-tame(2)-ed > program3 that allows execution of program1. How does your tame(2)-ed > program2 protect you now against executing program1 ? You still risk > executing it by using program3.
Crossing an execve boundary can be risky or not risky -- it depends, and your brush is too broad when you paint it all safe. Perhaps that is true for programs which INTEND to execve, but tame is also there for programs which were never supposed to execve at all, and then due to a bug, suddenly try to do so. > Besides, what if all programs are tame(2)-ed, does that > mean that no program will be able to call any other program anymore ? Don't understand that sentence at all. tame(2) is still incomplete. There are secret planned features not yet shared with the masses. tame is designed to be flexible and extensible; some features are coming which will help, but first we should use the existing tame features to solve the programs which only need them. By talking -- instead of reviewing or providing diffs -- you are not part of the solution. You being precipitate, that gunk at the dark bottom of the lake. Rise up to the sunlight, review some of the diffs that have been sent out, verify the ones that DO work, look for ones that subly need more, and wait for future features needed by programs which are a bit different. Instead of handwaving. > So unconditionally disallowing exec(2) for the purpose of avoiding bad > programs being run seems somewhat pointless to me. I don't think the attack > surface of those bad programs goes away, but maybe it's less visible. So run something like this: ftp -o - ftp://internet/file | col 1. That "|" is a fork + exec from your shell. 2. You're going to say you wouldn't do that. Except this is a microscopic example of what you do every second of your day -- taking untrusted data and running it through potentially buggy system tools. 3. Go look at the 20+ bugs fixed in the last year in col. 4. col contains no execve, but watch someone execve out of it due to those bugs. I do not want col to execve, so no tame feature allows execve at present. > I don't really understand why exec(2) is treated differently from other > potentially dangerous operations. I think it has a legitimate use. Gasp. > (I'd like to use it as "exec + whitelist of permitted 'trusted' programs") tame currently blocks all execve, and we won't go to such a list. Because that is not the problem in software. > I see each program as a different entity, each having different tame(2)-ing > requirements. I'm not sure tame(2) inheritance is very useful from that > point of view. tame inheritance over "fork" is definately useful, over 15 programs commited in base area already using it effectively and carefully. fork + kill, basically. tame cannot be inherited over "exec", because tame does not currently allow exec. > The main reason for running another program is probably because some > functionality is needed not offered by the currently running program. > I don't really see why the child program would need the same tame(2) > requirements, or a subset thereof. (maybe there are cases where this could > be the case, but I don't see a general usefulness) tame prevents all use of execve at the moment, so what you say is not relevant. > Please correct me if I'm wrong, but I see tame(2) as a means to reduce the > attack surface of the program it is used in, not as a tool to reduce the > attack surface of another program it knows nothing about. That sentence is correct. But I don't agree with your earlier premises, because we can do better than just this. We don't want col to run execve. This is a very common case. The case of wanting to allow execve is MUCH LESS COMMON. We'll get there, in short order, once the non-exec parts of the tree are taken care of. You may not be aware, but people load fresh code into programs when they attack them. Be patient. I am not adding all the planned layers to this subsystem in one go. There is something being designed for exec, and it will show up when the time is right.
