Re: Partitioning scheme for file/mail server

On Wed, 26 Oct 2005, Chan Tai Man suggested tentatively:
> Alex Butcher <alex.butcher.news1005@xxxxxxxxxxxxxx> wrote:
>
>> I prefer to keep /boot on /, and keep / entirely below the 1024 cylinder
>
> Is it logical size 7.84GB (255 heads x 63 sectors x 1024 cylinders x 512
> bytes), or physical size? I think I still confuse about the similarity
> and differences bewteen logical and physical geometries. If the later,
> wouldn't it mean that 1024 cylinder limit is a merely 504MB on my /dev/hdc?

It is the geometry as the BIOS sees it, whatever that is.

There is no visible physical geometry on modern hard drives (although it's
true that PC BIOSes rewrite even the geometry that the drive supports,
introducing yet another level of designed-in lies and complexity...)

> Disk /dev/hdc: 16 heads, 63 sectors, 155061 cylinders

It's that geometry that matters.

(In practice the only machine I own with a 1024-cylinder limit was
bought in 1997, and I've seen no machine newer than 1998 with that
limit. Plenty of newer machines have 137Gb limits (I think it is),
though...)

>> point. I figure it's one less thing to go wrong, and if it does, I've got
>> a minimal system I can (try to) fix it with.
>
> I was adviced, if I had understood those howtos correctly, that putting a
> small /boot at the beginning of a disk will guarantee that it will sit
> comfortably below 1024 cylinders (and so does /).

Yes.

> It will marginally
> increase security in the event of an automated attack (possibly not much
> if it were an human), 'cos I can mount /boot read only or not mount it all

The latter is a nice one, especially if it's not listed in /etc/fstab at
all so you have to run something else to mount it ;) pretty much no
automated attack tool will be able to get at it then.

However, the number of rootkits that replace entire kernels, or edit
them, is very low (nil?); the chance of the rebuilt kernel misbehaving
obviously is just too high.

Most kernels insert modules or patch themselves in via /dev/kmem or
/dev/mem: firewalls should turn modules off and remove CAP_RAWIO from
the capability bounding set to disable /dev/mem, /dev/kmem, and
/dev/port.

(If you're using stuff that needs modules, like digsig, it gets harder:
you'll have to disable the kernel's module loader after it's loaded
those modules. This is quite easy with a small kernel patch: I wrote
one but it's been described as unnecessary by people on l-k so I'll
not inflict it on you. I think `unnecessary' was probably a synonym
for `crap'...)

--
`"Gun-wielding recluse gunned down by local police" isn't the epitaph
I want. I am hoping for "Witnesses reported the sound up to two hundred
kilometers away" or "Last body part finally located".' --- James Nicoll
.

Relevant Pages