Stewart Stremler said:
> begin  quoting Neil Schneider as of Tue, Apr 19, 2005 at 12:30:52PM
> -0700:
>> Stewart Stremler said:
>> > 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.

I wasn't trying to address his point, only to say I wouldn't be a
member of any club he belongs to.

>> 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.

NO, They don't care. They're only interested in what they can do with
the computer, not whether it's secure. I deal with end users on a
daily basis and believe me, they don't care. I told a CFO some years
ago to get a radio, because he insisted he wanted me to open ingres
ports on a firewall to allow him to listen on the web. He should have
known better, but he didn't care. He just wanted what he wanted and
security wasn't even in the equation.

>>                    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.

Yet you seem to be supporting Michael's cavalier attitude.


> 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.

No, that's the point. They can't because the user who they're sending
programs to doesn't have permissions to run them. They'll send all
kinds of crap through IRC and AIM to your computer. If you don't have
the permission to install and run the code, you can't be compromised
by it. Root has no such restrictions. It's been a long standing rule
on IRC that you don't IRC as root. Wonder why that is?

>>                                 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?

I dunno, which is it?

>> 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.

I doubt seriously he'd accept the challenge. Since I can't stand him,
I'll not invite him. Someone else is welcome to.

> 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.

No, they were instrusion testing him. He was obviously inexperienced
and it showed in his presentation. Someone in the back of the room
nearly hacked him but he finally noticed. Corel took a lot of flack
back then, as they should, for running the default login as root.

>>                                 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.

Linux is a multi-user system. I don't care if there's only one user
logged in it doesn't change it into a single user system. Linux single
is single user. No network, no X, no multi-user. Sounds like a secure
Linux system to me! :-)

> With just one user, the user's home directory is the most important
> thing.  That data is what must be protected.

Login in single user mode then.

> 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.

Don't login as root.

> 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*.

Linux 1 is single user mode.

> [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.

If it logs you in anything but runlevel 1 it's mult-user.

>> > 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.

Since the standard reasons for not being root seem to be unacceptable,
then the argument is lost, before it's begun. I'll not participate.

>> 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?

All the servers on my SuSE systems run as seperate users AFAIK. Only
things running as root seem to be system services that need to.
Everything else seems to be running under it's own user. I didn't set
it up that way, though it's usually my choice, it's the default in
SuSE and I think it is in Fedora too, though to be honest I've not run
a Fedora system myself.

>>          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.

No, you're arguing that running as root is fine, so why do you care if
the developers want you to in order to install their software?

>> > 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.

Run in single user mode and you can't be compromised.


>> > 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?

Not in this thread, but in past arguments on this list. You have been
adamant at times about wanting to install packages in your home
directory, for testing. You have complained about your inability to
use a package manager to do so. If you mount the drive noexec, then
you can't do that.

Everything is a compromise. Running as root just compromises the whole
system. If you want to run as root, maybe you should start in single
user mode. :-)

-- 
Neil Schneider                              pacneil_at_linuxgeek_dot_net
                                           http://www.paccomp.com
Key fingerprint = 67F0 E493 FCC0 0A8C 769B  8209 32D7 1DB1 8460 C47D
Sometimes I wonder whether the world is being run by smart people who
are putting us on, or by imbeciles who really mean it - Mark Twain


-- 
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

Reply via email to