On Tue, Mar 20, 2007 at 12:14:17PM +0100, Oswald Buddenhagen wrote: > On Tue, Mar 20, 2007 at 07:28:36AM +0000, Dave wrote: > > On Mon, Mar 19, 2007 at 11:51:37PM -0400, Derek Martin wrote:
> > > I'd also really like to see a configure option for mutt refuse to > > > run binaries in directories where the user has write access, > > > > I think that's a useful option. > > > it sort of defeats ~/bin. Well, you can "lock" ~/bin by chmod(1)ing u+w ~/bin before every time you add or remove a local script/program, and u-w after you're done. > the most secure solution is already the default: no sane program (except > the linker) creates/saves files with an executable bit set. this is a > conscious decision of the user - at the point where it is not, the > security was already compromised. I don't disagree with your last statement. However, some people may appreciate the added bit of security gained by extra restrictions on program execution. > > > enabled by default, but whatever. > > > > Again, it shouldn't be enabled by default, unless the user has already > > informed his OS that he'd like the system to go out of its way to > > protect him. (Such a flag might also signal rm(1) to do -i by > > default, for example.) > > > this "user is [security wise] clueless" flag sounds a lot like the > concept of user expertize levels in general. a lot has been said why > this is a bad idea. check the [EMAIL PROTECTED] archive. I don't necessarily believe that user expertise levels are a good idea. My proposal is to ask the user at system installation time whether the system has permission from the user to make certain types of decisions on the user's behalf. The only purpose of that proposal is to allow security-conscious programs to automatically protect stupid users who are interested in that type of protection. A system wouldn't be required to ask the user for said permission at installation (so, for example, Slackware would almost certainly steer clear of that qusetion), but a system targetted primarily at cluless users would probably be doing its users a favor by asking such a question at installation time. The nice thing about the UNIX philosophy is that it doesn't preclude systems from offering innovative functionality targetted at particular types of users. It only requires that the default behavior not trample the user's freedom of choice. > derek's approach is counterproductive: users will always invent creative > ways of compromising security, and are even more motivated to do so if > the system behaves non-predictably (unix incompatible, as you say it). You're basically giving one of the indications supporting my assertion that the UNIX philosophy is the only way to compute that makes any sense. > otoh, most users *are* idiots (yes, even the unix users - Idiots have the right (a) to exist, and (b) not to have decisions that are rightfully theirs stolen by a zealous system, not even in the name of security. People don't lose their rights by being idiots. > most corporate > users don't choose their environment, You've been confused by our two uses of the term "user" in the discussion. When we talk about the user of a system, it's the corporation itself (the "guy" who bought the computer in the first place). The guy who sits at the keyboard and physically computes is just an agent of the "user." If the corporation decides to delegate certain decisions to the system in the interests of security, an employee of said corporation must honor the corporate decision. (Otherwise, our "user" has a split personality, and the system can't possibly hope to figure out what the heck he really wants.) > and the raising numbers of private > linux users doesn't exactly help, either), For them, there's a system-installation-time question allowing them to delegate security-related decisions to the system. > and even the most security > conscious ones make mistakes. It's up to an individual user to decide not to trust himself, if he knows he's in the habit of making mistakes. The system has no right to assume that the user doesn't trust himself. (That's the Microsoft philosophy, not the UNIX philosophy. Actually, I think the Microsoft philosophy is something along the lines of this: The user is just a user; his only right is to pay.) > when weighting the convenience of the > users against the future of a company and possibly thousands of > secondary victims, the decision is pretty clear. That's a business decision of a company, that it may make for its own systems (i.e., the ones that it's the user of). Obviously, it has no authority to make such a decision for its employees' personal systems, and certainly not for every Mutt user on the planet! > if there only wasn't > the previous paragraph ... You view the problem with Derek's approach in a purely practical way, and so your solution is to try to find a way around the problem. I view Derek's approach as fundamentally wrong, since it violates user rights. That's why I don't even try to get around the "problem." > so the key is to design security in a way that does not get in the way > of the users, so they don't try to work around it. As I said, your approach is to try to get around the "problem." To me, the key is to stick to the UNIX philosophy: to build small programs that pick one thing, and do it right. > an essential part of > that design is educating the users, btw. wow, that's what i call stating > the obvious. The only education a user needs is an introduction to the UNIX system, so he can understand the structure of his system, and make informed decisions. It's the user's responsibility to either educate himself or delegate decisions to others, but it's not our responsibility (or right) to enforce it. If I buy a radio control car, the car has no right to refuse to drive off the edge of my roof. (Incidentally, once you change to a real car, we open a whole new can of worms, since we bring in [OT] the ethical question of what your children's status is.) > so ... > regarding the umask i can only say that i never liked it - it's way too > broad and it always gets in the way. i determine default permissions by > putting stuff in the right directory ... To each his own. Mutt's responsibility is not to steal any decisions from you. > regarding the paths, i'm strictly against hard-coding anything in > the binary. I'm strictly against hard-coding paths anywhere, since providing paths isn't part of Mutt's job description. That's part of the job of the underlying operating system. If gpg poisoning worries you, replace execvp(2) with a wrapper that doesn't search $PATH for gpg, opting instead for a hash lookup or something to find the full path to the binary. > i can accept absolute paths determined at configure time in > the default config, I can't. The configure script has no authority to steal decisions from the user. The user owns his copy of Mutt, not the other way around. > but i don't think it is an advantage of any kind. I don't, either. - Dave
