Over the last couple of days, I've been working to set up an AI and IPS
infrastructure for a ZFS-based sort of flash archive installation, based
on the OSDevCon 2009 paper by Philip Torchinsky and Peter Karlsson:
http://www.osdevcon.org/2009/program_detail.html#philip
http://www.osdevcon.org/2009/slides/automated_deployment_of_hundreds_of_opensolaris_machines_philip_torchinsky.pdf
http://voyager-eng.livejournal.com/1155.html
While doing this, I've found and reported at least two serious security
issues with both AI and IPS:
15362 AI manifests are installed world-readable
http://defect.opensolaris.org/bz/show_bug.cgi?id=15362
I noticed that AI manifests are stored world readable on the AI server,
leaving the passwords in the embedded SC manifests accessible to anyone
with an account on the AI server.
15417 pkg.depotd lacks access control
http://defect.opensolaris.org/bz/show_bug.cgi?id=15417
As soon as pkg.depotd is started, anyone can publish packages to it,
thus also updating and highjacking existing ones.
Both bugs per se may not be reason for concern on their own, but at
least part of the response so far and the underlying mind set is, thus
I'd like to bring the issue to a wider audience.
In the first case, one could argue that access to the AI server could
(and should) be restricted, but this won't help at all since I learned
that anyone with an account on an AI client has unrestricted access to
the manifests. While e.g. the recent System Configuration SMF Service
design document has gone to considerable lengths to restrict access to
sensitive data on the install target (protecting the SC manifests to be
root-owned, mode 400, protecting SMF properties with read
authorizations, and removing the data wholesale once the configuration
has been applied, and consulted several security experts, Gary Wininger
and Darren Moffat among them), this is all useless if any AI client
local user has unrestricted access to the data anyway. And unlike the
AI server, AI clients are supposed to have local users.
Compare this to Jumpstart with NFS, where the filesystem provides at
least some sort of access control, however weak with AUTH_SYS only, so
access can be restricted to the root user on the Jumpstart client,
which may be enough in a restricted environment. To me, this seems like
a serious regression, and there's no warning or even hint about the
issue.
The second case is even worse, in my opinion. As soon as you start a
local repository, it will by default be read-write to anyone who can
access the repo at all. This obviously opens the door to all sorts of
break-ins, like publishing updated packages which include either trojan
setuid root binaries, or SMF services and method scripts which can do
about anything on the clients of the repo. This issue has been known
for at least two years (Bug 689), but nothing has been done about this
so far. You can start pkg.depotd with --readonly, but then nobody can
publish except directly into the repo via the filesystem; the necessary
procedure to do so isn't properly documented.
Even if some of the maintainers claim that IPS is still in development,
it is already deployed in the wild, and the OpenSolaris releases are
supposed to be Sun/Oracle supported products, not some internal toys.
Even if full authentication support cannot be implemented immediately,
at least some minimal sort of access control is needed, like restricting
write access to localhost or a particular group of IP addresses.
Everything is better than the current complete lack of access control.
What's worse, in both cases, there's not even a hint as to the problem,
or documented workarounds until anything better is in place. I can't
help but feel that the developers seriously lack consciousness for
security issues like this. Claiming (as Shawn Walker has done) that
security/access control is just a missing feature like others (that
cannot even be documented due to lack of man power) is similar to a SVN
1.0 release that allows everyone write access to the repo without even
mentioning the fact. Imagine Jeff Bonwick coming along a couple of
years ago, saying: "We've developed that wonderful new filesystem, called
ZFS. It has tons of exciting features, but we haven't gotten around to
designing or implementing that miniscule featurette called access
control: anyone can read and write every file. I'm going to put this
back tomorrow, and think about that little thing once I get a free minute
or two." He would have been ridiculed, and rightly so: security is not
just another add-on feature that you can add at your leisure, but needs
to be designed in from the beginning.
I fear the current situation is highly dangerous, and I'm getting
nowhere with those bugs. It needs to remedied ASAP, even if for the
moment this consists in simply defaulting pkg.depotd to read-only mode
and *strongly* documenting the risks involved in read-write access and
and possible workarounds. I'd like to avoid the situation when a site
has been broken into (even from the inside) by use of those holes.
OpenSolaris doesn't need that kind of publicity.
Thanks.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
