Date: Mon, 11 Aug 1997 12:11:26 -0700 From: Sean Eric Fagan <sef@Kithrup.COM> To: ache@nagual.pp.ru, bde@zeta.org.au, current@freebsd.org, security@freebsd.org Subject: Re: procfs patch Message-ID: <199708111911.MAA23776@kithrup.com>
next in thread | raw e-mail | index | archive | help
>Useful for what? Even if they are equal at the moment you check it not >means that program was not setuided before your check and have secret data >in memory. Why are people having such a hard time reading the code? (Well, Bruce has -- I disagree with his objections, but he *has* read teh code, and does seem to understand what's going on.) The only "secret data" you have in memory after an exec would be file descriptors, and environment data. You can get the environment data by sending a core-dumping signal to the process. You can attach to it with ptrace(). You can read its memory with /proc/<pid>/mem. THe process does not have P_SUGID set. Because it has done an exec since the last setuid/setgid. THis is clear if you read the kernel code. >> My patch is no different than the situation with core files. If a process >> has your UID, you can make it dump core, and then examine its data. This is >> an extensio of that. > >As I already write you, it is false in general case. If program was >setuided, you can't make core from it even it runs with your UID >currently. I don't see an extension here but old security hole (core-like >one) reopening as I warn already. Consider this: you run suid program it does some stuff, then sesetuid's to you it then exec's a program, as you You can make that last program core dump. Got it? It can core dump. It can core dump. It can core dump. I don't like repeating myself, but people don't seem to be reading. In teh above case, with my procfs changes, you cannot read the suid program's memory. YOu cannot read the suid program's memory after it setuid's to you. YOu can read the last program's memory. This is no worse than the core dump case. Because you can make it core dump, because it is you, and P_SUGID is not set. If you *read* the code I sent out, you'll see that it checks for P_SUGID being set, and fails (assuming the requesting process is not suser()). Is that clear yet? Do I need to repeat myself again? (Yes, I'm getting frustrated here.) >Now I like Bruce's idea that exec call should fail if procfs memory is >open and setuid program is executed. I don't. I hate it. It's bad. It makes things difficult for programs that want to use this. It is also unnecessary -- my changes do not have that particular hole. (IT's bad because it fails the principle of least surprise. You can't really argue "traditional unix semantics," because procfs was not in traditional unix. You can try arguing what SysVr4 does, but I'm not sure what that is. You can try arguing security -- but you'd darned well better be prepared to fix *everything* then, and not just spot check. You can try using traditional unix semantics as a guideline, and that's what I've done, in both this case and the rfork/exec case. And that boils down to: useability and principle of least surprise.) Once again: my procfs changes, for the most part, are no worse than core dumping. So, Andrey, why don't you go around demanding that core dumps be completely disabled. When you do that, I'll start to have some respect for your position; until then, you're just going to impress me as someone who hasn't read teh code I sent out. Is there still a security risk? Yes. It's very slight, and I can argue that most of the cases it matters are bad programming anyway. But it's there. But it is there without procfs, in the form of PT_ATTACH in ptrace. ANd much of it is there with core dumps. Sean.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708111911.MAA23776>