-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
When I login as root I have full root privs. SE Linux is not something
you are going to run into from a properly authenticated shell. If you
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.
> But that would be one reason to avoid running as root -- a trojan'd
> machine would not have some avenues open to it when the single-user
> account is compromised vice root.
Yep.
> If it hasn't prevented you from doing anything clever, then it must be
> running in name only. How will this help?
See above.
> 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. Viruses traditionally do not hurt your data. Why do people buy
anti-virus software?
> 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.
> 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.
> 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.
> So... software mitigation. A sort of geeky approach would be to
> have sandboxes. Another would be a VMS-style filesystem where the
> data is NEVER deleted. A sort of CVS-for-a-filesystem. Changes are
> logged by user, program, and ancestor program (programs that forked
> all the way back to init).
Isn't running as your own uid a way of sandboxing your own activities
from those of the system? A leaky sandbox, but it's a start along those
lines. 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. I understand that is the main reason why unix does not have
undelete.
> 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. For example, on one of my servers I have the
following setup:
Device Boot Start End Blocks Id System
/dev/hda1 * 1 261 2096451 83 Linux
/dev/hda2 262 392 1052257+ 82 Linux swap
/dev/hda3 393 9729 74999452+ 8e Linux LVM
So hda3 is one big partition as far as the traditional idea of a
partition goes. But...
/dev/hda1 2096380 367300 1729080 18% /
/dev/system/var 5160576 1813664 3084768 38% /var
/dev/system/usr 4194172 1863032 2331140 45% /usr
/dev/system/local 33553404 32040208 1513196 96% /usr/local
/dev/system/home 20970876 13123076 7847800 63% /home
none 257300 0 257300 0% /dev/shm
That one big disk partition is actually formatted as a LVM physical
volume which is part of a volume group (called "system" in this case and
consisting of one disk) which contains the above 4 logical volumes.
# /sbin/vgdisplay
- --- Volume group ---
VG Name system
VG Access read/write
VG Status available/resizable
VG # 0
MAX LV 256
Cur LV 4
Open LV 4
MAX LV Size 255.99 GB
Max PV 256
Cur PV 1
Act PV 1
VG Size 71.52 GB
PE Size 4 MB
Total PE 18309
Alloc PE / Size 15616 / 61 GB
Free PE / Size 2693 / 10.52 GB
VG UUID uKFl0M-5xej-THek-w0HG-44QD-UQ2h-JceTwl
This shows me that in the volume group named "system" I have 10.52G of
unallocated disk space in the "system" volume group. Now I create a new
logical volume:
/sbin/lvcreate -L5G -n testing system
lvcreate -- doing automatic backup of "system"
lvcreate -- logical volume "/dev/system/testing" successfully created
So now vgdisplay says:
<snip>
Alloc PE / Size 16896 / 66 GB
Free PE / Size 1413 / 5.52 GB
<snip>
And we have a shiny new logical volume in which to make a filesystem:
# /sbin/mkfs.ext3 /dev/system/testing
mke2fs 1.34 (25-Jul-2003)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
655360 inodes, 1310720 blocks
65536 blocks (5.00%) reserved for the super user
First data block=0
40 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 32 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
# mount /dev/system/testing /mnt
# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda1 2096380 367876 1728504 18% /
/dev/system/var 5160576 1813872 3084560 38% /var
/dev/system/usr 4194172 1863032 2331140 45% /usr
/dev/system/local 33553404 32040232 1513172 96% /usr/local
/dev/system/home 20970876 13123240 7847636 63% /home
none 257300 0 257300 0% /dev/shm
/dev/system/testing 5160576 32828 4865604 1% /mnt
Voila. I could also lvextend and then resize the filesystem on the fly
if I needed more space in an existing logical volume. Same with
shrinking if maybe I initially allocated too much to /var and need more
in /usr/local. Now to reclaim the space since I don't really need that
5G logical volume:
# umount /mnt
# /sbin/lvremove /dev/system/testing
lvremove -- do you really want to remove "/dev/system/testing"? [y/n]: y
lvremove -- doing automatic backup of volume group "system"
lvremove -- logical volume "/dev/system/testing" successfully removed
And now my vgdisplay output is just like it was before I created the new
logical volume/filesystem.
>>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.
- --
Tracy R Reed
http://[EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD4DBQFCZTzL9PIYKZYVAq0RAr8pAJ9dh3K9Mq8RXEpocbM6/EnBJZ7gQACYhEu1
w50P9TtV+qBzfU4i8uaL/Q==
=TMsW
-----END PGP SIGNATURE-----
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
