In article <slrndbuhkv.sa6.usenet@gaia.roc2.gblx.net>, Dan Foster <usenet@evilphb.org> wrote:
> In article <d9ng91$gf5$1@neuromancer.cse.psu.edu>, John D Groenveld <groenvel@cse.psu.edu> wrote:
>> In article <slrndbue8u.sa6.usenet@gaia.roc2.gblx.net>,
>> Dan Foster <usenet@evilphb.org> wrote:
>>>So Sun bloggers may not want to slag Linux just yet...
>>
>> Is Linux embedded in the service processor for the Galaxy servers?
>
> Hm? No idea.

Ahh, correction. If Galaxy includes V20Z, then yes.

I'm aware of some of the internal code names (e.g. Einstein for the
Ultra 5, Daktari for the V880, etc) but not for most of them. My apologies.

The V20Z service processor (a PowerPC at 64 MHz, possibly a PPC 860?)
runs a small OS off nonvolatile flash RAM -- Linux 2.4.18.

It's a rather minimal environment since the amount of flash RAM seems to
be constrainted, presumably for cost reasons. I don't recall the size
offhand, but want to say it's 16 MB or 32 MB?

It does make me slightly nervous because the ssh (both client and
server) on the SP is OpenSSH 3.4p1. Hopefully, it's well patched against
the holes found since 3.4p1.

We do limit access via network/firewall access control lists to minimize
the potential for malicious exploitation even if unpatched.

This is a common issue with any 'black box' appliances, Linux or not.

We've had remote root compromises with FreeBSD-based appliances because
the vendor configured it incredibly poorly and didn't let us have access
or tell us about its weaker points.

Unusual network traffic was how we noticed and found the underlying
culprit. We ended up not buying that particular vendor's hardware, by
the way. (We also isolated all appliances after that incident, years ago.)

The issue is compounded, over time, when the vendor eventually stops
introducing patches for an existing product as it ages -- including
security fixes.

So the policy with anything involving appliances and network
connectivity has always been to 'lock it down as much as possible'.

-Dan