begin quoting Tracy R Reed as of Wed, Apr 20, 2005 at 12:15:56AM +0700: > Stewart Stremler wrote: > > I don't see a lot of that mitigation going on. (And if you're using > > SELinux, running-as-root shouldn't be a problem, as root isn't really > > root, right?) > > It is all a matter of contexts. The way FC3 is set up you as a user > shell can't really get into a restricted context unless you try. For > example ps -ax --context shows me: > > 4030 user_u:system_r:named_t /usr/sbin/named -u named > 3636 user_u:system_r:syslogd_t syslogd -m 0 > > These two daemons are runnning in a greatly restricted environment. That's not really applicable to the proposed situation -- the advantage of a single-user box running as a 'normal' user or as 'root'.
> When I login as root I have full root privs.
No su or sudo?
> SE Linux is not something
> you are going to run into from a properly authenticated shell. If you
So a trojan'd user process won't see these restrictions either?
> obtained your shell via a buffer overflow in an SE Linux protected
> daemon like named you would find your abilities severely curtailed, if
> it could even execute a shell at all since named would not normally need
> that capability to run.
That's a multi-user protection. Single-user machines don't offer
services on the network, as that would make them a server, which
selects them out of our consideration for the moment.
[snip]
> > If it hasn't prevented you from doing anything clever, then it must be
> > running in name only. How will this help?
>
> See above.
Likewise. Not a concern for a single-user box.
> > I don't think the 'average' single user _cares_. The point is that
> > there *data* is what's important, not the OS. Not the applications.
> > All that can be recreated. What can't be (easily) recreated is their
> > data.
>
> Sure they care. If their system gets hosed and starts crashing or
> whatever it is a real inconvenience even though their data may still be
> safe.
How will their data be safe?
Handwaving doesn't make it safe.
> Viruses traditionally do not hurt your data. Why do people buy
> anti-virus software?
Excuse me, what tradition is this?
People buy anti-virus software because they're told the need to, instead
of learning good habits. It's trusting that software can solve the problem,
instead of changing behavior.
> > Of course they'd like to prevent having their operating system files
> > trojaned, because we tell them that trojaning in bad. Can that explain
> > _why_ it's bad? I don't think so. "My {{son,daughter}{,-in-law},friend,
> > sibling,neighbor} said it was bad."
>
> On the Windows platform it is bad because it slows down your computer,
> leads to crashing, uses up precious system memory, etc. I think the
> average person can understand this.
How is this different from the average application program?
I'm perfectly cable of slowing down my computer and using up precious
system memory as a regular user -- and now-and-again to the point of
crashing the system.
(This is one of the reasons I got a solaris box at home -- it degrades
more gracefully under extreme stress than any of my x86 linux boxen ever
have, aside from the early slackware box.)
"Avoiding crashing" kind of leads us out of the security arena -- loss
of data or compromise of the system doesn't _always_ lead to instability.
> > The user's primary concern is their data. Being a good network neighbor
> > is pretty far down the list... except to geeks. That's why we're so
> > much more annoyed by this than the 'average' person, I think.
>
> Actually, I don't think they give a care about their data. Nobody does
> backups. When they lose it, it's gone. If they really cared they would
> back it up.
Really? With what tools?
Managing backups is _not_ something the average user wants to learn
about.
> > Don't discount the user's data - that just gives the impression that
> > the Linux geeks disregard what's important to the non-technical user.
> > "Microsoft says the user's data is IMPORTANT, the Linux community
> > doesn't, and goes on about how its important for the OS to be safe."
>
> The users discount their own data by never backing up. But lets assume
> it is a corporate user who really does have valuable data and does back
> it up regularly.
Bad-mouthing the users in this way just drives home the point that geeks
are elitist and condescending.
[snip]
> Isn't running as your own uid a way of sandboxing your own activities
> from those of the system?
Why do I care about the rest of the system on a single-user machine?
> A leaky sandbox, but it's a start along those
> lines.
It's a _start_. But it's being touted as 'enough'. Which it is isn't.
The LFS crowd has an interesting idea w/r to user-accounts. Some say
that _every_ package should have its own user-account. Install a new
package, and you make a new user-account for it. That way you get some
nice partitioning, plus you can tell by _looking_ at a file what package
that file is associated with.
I've not heard of a mainstream distribution who's done that yet. But
that seems like a useful _second_ step. . .
> Security in depth and all. I like the idea of a VMS style fs but
> you are right in that purging the history in a secure yet useful way is
> interesting.
It gets harder with proprietary formats...
> I understand that is the main reason why unix does not have
> undelete.
UNIX presumes an operator who will do routine backups.
It doesn't seem to be designed with a single-user in mind.
> > Can you retroactively partition a disk? Or is that "create a partition,
> > copy, delete, mount"?
>
> Yes, you can retroactively partition a disk. On the fly even. Although
> it's not really partitioning but it serves just as well. What we care
> about are filesystems as seen by the OS and filesystems are created
> inside of logical volumes.
Yes, 'partition' in this sense being that which is seen by the OS. The
functionality offered by LVM in this case isn't any better than just
not allocating some disk "for future use".
It's one of "Oh, /usr needs to be its own partition! <clickety-click>"
vice "fdisk /dev/blah <allocate a new partition>; newfs /dev/blah;
mount /dev/blah /mnt; cp -rp /usr/* /mnt/; mv /usr /usr.old; mkdir /usr;
umount /mnt; mount /dev/blah /usr"....
[snip]
> >>Definitely. I see what Lindows is doing as encouraging bad habits.
> > ...which puts the problem back in the user camp, not the software. His
> > question stands...
>
> I don't think so. I think some pretty good reasons have been listed as
> to why it is better to run as a non-root user.
I think I've seen _one_ half-decent reason that *sometimes* applies.
-Stewart "Not convinced by the arguments proposed yet" Stremler
pgpz5uG7tLHc0.pgp
Description: PGP signature
-- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
