[techtalk] partitioning security (was lilo)

[coldfire]

> > very true .. throwing everything on one partition is a potential security
> > risk and could also make your machine less stable.  i won't go into detail
> > (i'm somewhat ethical ;p) on these issues ..
> 
> So ... I don't want to compromise your ethics or give info to crackers,
> but can you at least give some hints as to why this setup should be 
> any less secure or less stable?

well, since i doubt there are a lot of crackers on the techtalk at
linuxchix.org mailing list .. i'll elaborate ;p

let's suppose that you have the entire filesystem mounted on a single
partition (/).  an attacker could do a number of things .. if they had
shell access without quota, they could write a simple program that forks
and recursively creates directories effectively consuming all of the
inodes on that filesystem.  granted, a small percentage of the filesystem
is reserved for the superuser, this would cause all kinds of problems with
other processes that attempt to create temporary files, logs, etc.

it's very simple to have the same effect on a system remotely (logs).

> > but it's always a good idea to mount /tmp on it's own partition.  i mean,
> > it's world readable and world writeable.  having this on it's own seperate
> > partition prevents users from being able to make hardlinks to privledged
> > files for example.  the same could apply for /home and other points.
> 
> So?  When you make a hard link, the owner and permissions are
> preserved; if you couldn't read the file before, you still can't.

sometimes the goal isn't to create a hardlink to a file and read it via
the hardlink.  perhaps you know of a suid executable that creates
temporary log/whatever files in /tmp (or even the users home directory).
if you create a hardlink with the name of that temporary log/whatever file
to another file for which you do not have write permissions .. well guess
what, you have write permissions now.

that's one of the main reasons that /tmp is normally mounted on it's own
partition.  i think it should be standard to at least mount /home on a
seperate partition as well.

> There can certainly be performance wins from moving certain directories
> to other partitions or, better, to another disk.  It especially helps
> with /tmp and swap, and around here we often put our build directories
> on a separate partition from where the compiler lives, for various
> reasons.  It's also useful to make a small partition (ideally on
> another disk) to carry vital info about the linux system (fstab and
> other system files, and maybe your home directory dotfiles) in case
> of problems.  But that's not a security issue.

nothing beats mounting filesystems on seperate disks.  i'm not sure if
it's actually a performance gain to have several partitions though .. i'm
not very knowledgable about this .. but my logic tells me that if there
are several partitions and you have a slow seek time on your drive ..
well, running something on /dev/hda1 that accesses config files on hda2
which then writes to a file on hda3 and moniters whatever on hda4 .. lots
of seeking going on.

> I've set up systems with several small partitions and systems where
> everything was on one big partition, and haven't seen any stability
> problems with the one-big-disk setup; if anything, the several-small-
> partition systems are sometimes less stable because eventually
> (perhaps not now, but a year from now when you upgrade to a newer
> system which takes much more disk space than the system for which you
> set up the partitions) you run out of space to install things and
> either have to resort to a web of symlinks (ugh) or wipe the system,
> repartition and start over.

to be honest, i bet the overwhelming majority of users could just put
everything on a single partition and be absolutely fine.  you don't have
to anticipate what you will install and where, etc.  much easier.  i agree
completely.

hehe .. i knew nothing about where slackware8 installed what and ran into
a bit of a problem .. i created a nice 200Mb partition for / and didn't
know that they now installed all of the gnome stuff under /opt.  needless
to say, that root partition filled up rather quickly during the install
and gave me a buttload of error messages. :)

> > i always like to have /var mounted on it's own partition.  this way, if an
> > attacker decides he wants to flood my box with something .. whatever it
> > may be .. if it's logged, when the logs fill up the partition entirely, it
> > won't crash the root partition.  i guess this could apply for /tmp as well
> > (and possibly other points).
> 
> Sure, I've set up systems where /tmp was a separate filesystem for
> that reason.  Is that considered a security issue?  So we're not
> talking easier to break into, just slightly more vulnerable to 
> flooding types of attachs?

/tmp usually isn't the first place you look when you want to root a box ..
but there are plenty of programs out there that aren't entirely security
focused for which exploits exist that would allow a user to read another's
sensitive files when they don't have the read permissions on those files.


sorry if i made this lengthy .. i honestly tried to keep it brief :)


abe