-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 2:56 AM +0900 10/19/01, Jim Cooper wrote: >1. The fault here seems to be the implementation of the Recent Items Menu. > -Recent Items opens apps as root user automatically if a setuid >app is on the top of the window z-order. -- a serious fault. > -Dock does not. > -Recent Items opens apps as root user if a spp which has been >opened by a sudo invocation is on top of the Z-order list. > -Dock does not. >--therefore I disagree... the problem *is* the Apple menu's way of >launching and dealing with forks as you originally suggested. Net >Info manager is not launching anything, Neither is BBEdit at that >moment, though they
My point is that the Apple Menu is part of the UI toolkit. It's not placed there separately. While it *looks* like a single menu that's always there, it isn't. It's put there by the application, even though it doesn't know it. Architecturally it is very different than the Dock, which is a separate application which can be killed and restarted. You can't kill and restart the Apple menu. I'm just pointing out that the implementation is such that the UI library code has to be rewritten. (Actually, we're agreeing violently, I'm just trying to make an architectural distinction as to *why* this is a problem.) Don't forget that it's not just the Apple menu. Services have the same problem. I suspect that Contextual Menus could as well, although I'm not sure. >might want to consider something about the implementation of the >invocation of Terminal.app for running Perl Scripts and the >Debugger. opens as root when terminal is closed. runs as current >user if terminal is already open. Anyway, this is one example where >one app does launch another. I don't understand what you are asking for here. If I run BBedit as root, and it launches Terminal, then Terminal should definitely be launched as root. Otherwise it may well not have permissions to view or run the stuff I just edited. You definitely need to be careful in that situation, but you bought into that when you ran BBedit as root in the first place. There's no security hole in that situation though. >--if I start with a blank desktop... open one app by sudo, then open >another from the recent items, and keep doing that...potentially, it >is the same as if I had logged in as root and was running >potentially damaging stuff. (except the finder) That is correct. Unless you limit sudo using it's class support, anyone with sudo access has complete root access to the machine. That's how the OS is designed. An ACL-based system wouldn't be as wide open, it would however be more complex to administrate. Think of permissions on Unix as rather like a one-button mouse. It's all or nothing :-). >3. Apple was originally reluctant to provide the Apple menu... then >it "suddenly appeared". Apparently, lot's less thought into that >than the Dock and the rest of the UI. True, but the problem exists even without it. I can get a root TextEdit application in any setuid program that has selectable text. >The question is: >should we be able to get permanent root access by invoking the >default shell as in my >previous example? Yes. Changing that behavior would require re-writing the operating system. I would recommend that if you are concerned about this, configure /etc/sudoers to restrict the commands that sudo can run to a set that you specifically see a need for (and obviously that should not include any shells, or anything that can launch a shell). However, the simplest solution is to create user accounts that aren't in the admin group (which none are, except the first one, if I recollect properly). Then none of your users will be able to sudo except the admin user, an account with a password known only to the administrator. I haven't set up multiple users, so I don't know if you can select which one logins in by default without the login screen. If you can, then simply create a new account on the machine and make it the default. The machine boots into that account, and nobody can run sudo except you. Alternatively, remove your primary user from the sudo list. Then any root access will have to be made by logging in as root. I think what does come out of this is that Apple should be more clear at install time about the implications of a single-user vs. multi-user install. You want to do a multi-user install on any public machine, even if there's only one logical user account. >5. I can think of some way to exploit this with a executable >applescript that Explorer could launch from a web_page. more is >best left unsaid. Utilizing the "I'll just run that binhex application for you" bug, or without? If there are other ways to easily execute applescript from explorer then those should be reported and discussed. - -- Kee Hinckley - Somewhere.Com, LLC http://consulting.somewhere.com/ [EMAIL PROTECTED] (or ...!alice!nazgul for time travelers :-) I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Security 7.0.3 iQA/AwUBO88cwiZsPfdw+r2CEQJwTwCeM1aZwnZx4beO4h1K8fFfhk0PAR4An2gp Qq+ttIhCy763wtvEWCKXLpts =VrNm -----END PGP SIGNATURE-----
