begin quoting Neil Schneider as of Tue, Apr 19, 2005 at 12:30:52PM -0700: > Stewart Stremler said: [snip] > > But Tracy's arguing that they ARE interested in security. > > I think he's arguing that security is a "Good Thing (tm)". Well, that too.
[snip] > > So you're in Michael's camp? > > I'm not in any camp that Michael's in. I personally think he's the > equivelent of a used-car salesman, in other word, he's a slimeball. Heh. But that's just calling names, and it fails to address his basic point. > However, user's don't care a thing about security, until it > compromises their data. They prefer closing the barn door after the > horses are all gone. I don't think that's "don't care a thing". I think that's just a matter of the inexperienced not understanding the ramifications of the problem. > Michael's cavalier attitude only enforces this. He's not the only one with a cavalier attitude. I've been ranting about some cavalier attitudes for years, to no avail. :-P > No need to worry about security now, I'll wait until I lose all my > data, then blame someone else. Michael said it was fine to run as > root, so it's his fault! So they have someone to blame, and are happy! [snip] > >> however I've not seen you make any serious suggestions about a > >> better alternative. > > > > Better than what? > > Better than not running as root. HOW? In a single-user non-dual-boot system, how is not running as root more secure than running as root? > Run your system as root, use gaim or > IRC or any similar program, let's see how long before your system and > your data are both compromised. If they can compromise my system as root, they can compromise my system as a regular user. I'm screwed both ways. > Most IRC networks will probaby kick > you off. But some script kitty on AIM will own you before long. If So why does this only happen as root? Is it that you mark yourself as a target and are probably running an insecure/undersecured machine? > Michael came to a KPLUG meeting, hooked his computer to the network, > and ran as root, my guess is that his system would be owned before his > two hour presentation was up. Sounds like a challenge. Invite him to do so. It would be amusing. He doesn't even have to present -- just show up, put his machine on the network, tell everyone his IP... come up with a prize -- if nobody can crack his system, he gets the price, if someone does, they get the price. Target: Delete the file named "DELETE.ME", or corrupt its contents. > It would serve him right, if someone in > the group simply removed all his files and crashed the system. It > nearly happened to the Corel rep in a similar situation. We had someone hack the Corel rep? Whoops. That's nice of us. [snip] > There are no panaceas except in some people's minds. Saying something > is not one, is not an argument. Point at SELinux and chanting "neener neener neener we're secure" does not an argument make, either. > Running as root is less safe than > running as a user. Saying there is no difference is irresponsible, at > best. The argument seems to be _HOW_ is it less safe? A lot of people confuse multi-user system constraints with single-user system constraints. With just one user, the user's home directory is the most important thing. That data is what must be protected. With TWO users, the situation changes drastically. Losing just one user's data is bad, but not as bad as losing the data for BOTH users. So _system_ security becomes paramount. You protect the system so that a compromise of one user does not affect the other user. This transition point seems to be what a lot of the disagreement hinges on. People bring multi-user concepts into the single-user situation, and stumble over the fact that the problem *changes*. [snip] > As has been reported, it already works that way on FC3, except for > special roles for root. But then that mostly covers services, and your > presumption is that this machine doesn't do services. Does > Lindows/Linspire do services? It oughtn't. If it does, that's a separate issue, as it's no long a single-user machine, but a server. > > Lessee... sandboxes, VMS-style filesystems, user-training, not > > allowing programs to check for uid 0 (probably can be done with > > fakeroot), per package user accounts, and partition restrictions. I > > consider the beating up developers who demand root access for their > > software as only sort-of constructive. > > Michael is doing user training. He's training users to ignore best > practices and run as root. You seem to think that's ok. No, I'm arguing that the arguments against it (almost) all suck. Yes, he's mistraining the users. That was the objection I raised. But his /actual/ question still stands... and Tracy has been the only one who has come up with a real answer, albeit one that applies in a fairly limited situation. Argue against the argument, not the person. > VMS filesystems are not Linux, have you worked on porting them over, or > are you just a cheerleader on the sidelines? VMS-like or VMS-style, please. The constraint is that all changes must be preserved, not just the N most recent ones. > Per package user accounts > for servers, are pretty standard on most Linux systems these days, I > believe. Really? Which distros? > If you're running as root, why do you care about developers > demanding root access, you already accomodated them. You've got that one backwards. If you're already accomadating them, you might as well run as root. > > Seems like I've provided the _most_ constructive feedback of *anyone* > > in this conversation. > > > > There's a little devil's advocacy involved, yes, because too many of > > the arguments for root/non-root distinctions are so poor. I > > personally believe in the root/non-root distinction, but I want > > defensible arguments. > > So what are your defensible arguments? Don't run single-user linux on a dual-boot machine. > > I've seen ONE where the distinction made for an important difference > > thus far. I want more. > > So provide some. Linux doesn't have the tools in place to make that distinction useful for single-user non-dual-boot systems. > > You don't get sharp arguments by cheering. You get 'em by applying > > the whetstone of logic and contrarianess. > > Sometimes it's just annoying. And crappy arguments aren't? I'm plenty annoyed. I've decided to be generous and share. Seriously, we have a 'so-and-so sucks because he says something we don't agree with' and not a lot of sober analysis of the pros and cons of his position. All-or-nothing reasoning is rarely reasonable, and it's quite annoying. [snip] > > It reflects the fact that something is broken in X. > > Does it? Or does it reflect that your assumptions are wrong? It may be that my assumptions are wrong. I'm willing to explore that issue, but that's worth a separate thread. If you want to spin up a discussion about the pros and cons of executable home directories, I think it would be worth discussing. I'd like you to take the noexec position, so I could avoid Yet Another Negative role. > > Why would anything in /home need to be executable for non-developers? > > > > If you enforce that policy with SELinux, does X still work? > > You can't have it both ways. You want packages to install in your home > directory, so you don't have to be root to install them, but you want > to mount /home noexec. They are mutually exclusive, are they not? I suspect you're confusing different arguments. Where, in this thread, have I recommended installing packages in $HOME? -Stewart "Note the qualifiers, please." Stremler
pgpkwKKYsqKiv.pgp
Description: PGP signature
-- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
