Looking for Advice on Debian Server Setup

[Eric Shubert]

VMs have changed the landscape a bit regarding partitioning.

The way I see it, there are two reasons for setting up separate partitions:
1) prohibit / from filling up so the system doesn't freeze
2) isolate user data from system/os data
The 2nd reason is somewhat related to the first.

Depending on how space is allocated to the VM, #1 can be a bit less 
likely to happen than on a hard iron host. For instance, if space is 
overallocated and your guest machine is monitored, separate partitions 
won't buy you much real benefit. If there's a way that / can be expected 
to fill up though, you'll want to take whatever measures are necessary 
to prohibit that from happening.

Of course, all this depends on the service level you expect to achieve. 
One size does not fit all. Whether your CMS is public or private is also 
a consideration, as is other security measures (firewalls) that are in 
place.

I expect it's time to hear from Lisa now. ;)

Mark Phillips wrote:
> I thought I would just quote the manual to see if it makes sense to 
> follow it (pages 35-36):
> 
> Any directory tree which a user has write permissions to, such as e.g. 
> /home, /tmp
> and /var/tmp/, should be on a separate partition. This reduces the risk 
> of a user DoS
> by filling up your “/” mount point and rendering the system unusable 
> (Note: this is
> not strictly true, since there is always some space reserved for root 
> which a normal user
> cannot fill), and it also prevents hardlink attacks.
>  
> A very good example of this kind of attacks using /tmp is detailed in 
> The mysteriously persistently exploitable program (contest) 
> (http://www.hackinglinuxexposed.com/articles/20031111.html) and The myste-
> riously persistently exploitable program explained 
> (http://www.hackinglinuxexposed.com/articles/
> 20031214.html) (notice that the incident is Debian-related). It is 
> basicly an attack in which a local user stashes
> away a vulnerable setuid application by making a hard link to it, 
> effectively avoiding any updates (or removal)
> of the binary itself made by the system administrator. Dpkg was recently 
> fixed to prevent this (see 225692
> (http://bugs.debian.org/225692)) but other setuid binaries (not 
> controlled by the package manager) are
> at risk if partitions are not setup correctly.
> 
> Mark
> 
> On Mon, Apr 27, 2009 at 7:49 AM, Austin Godber <godber at uberhip.com 
> <mailto:godber at uberhip.com>> wrote:
> 
>     I have occasionally found it handy to have /tmp on a separate
>     partition.  Mainly to ensure that /tmp doesn't fill up accidentally
>     which can lead to all sorts of unpleasantness and complicate recovery.
> 
>     Same applies pretty much across the board and bi directionally.
> 
>     Though separating out partitions of course comes with slightly increased
>     complexity.
> 
>     Austin
> 
>     James Finstrom wrote:
>      > This was discussed a week or so ago (sorta). Generaly you want to
>     keep
>      > home on it's own partition. Never seen the rest but could see some
>      > logic with var and opt not really tmp
>      >
>      > On 4/27/09, Mark Phillips <mark at phillipsmarketing.biz
>     <mailto:mark at phillipsmarketing.biz>> wrote:
>      >
>      >> I am setting up a new server for Plone/Zope sites on a Linode
>     VPS. Reading
>      >> the "Securing Debian Manual" (
>      >> http://www.debian.org/doc/manuals/securing-debian-howto/), it
>     recommends
>      >> separate partitions for /tmp, /home, /opt, and /var. I was
>     talking with some
>      >> of the Linode folks on IRC to find out how to set up separate
>     partitions,
>      >> and they felt that it was unnecessary to have separate
>     partitions for a
>      >> production server (regardless if it is on Linode or not).
>      >>
>      >> I am interested in any opinions on the subject from this list.
>      >>
>      >> Thanks!
>      >>
>      >> Mark
>      >>
>      >>
>      >
>      >
> 
>     ---------------------------------------------------
>     PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
>     <mailto:PLUG-discuss at lists.plug.phoenix.az.us>
>     To subscribe, unsubscribe, or to change your mail settings:
>     http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
> 
> 


-- 
-Eric 'shubes'