Jens Elkner writes:
> Furthermore (kind of OT): Some people/unexperienced user might
> think, installing the package in the global zone, inherited it and
> just disable the unwanted service might be safe. But as more
> experienced users know, just having a service not running does not
> prevent anybody to executed a program. And thus a security threat
> might still exists. E.g. suid xterm, suid sendmail and who knows,
> which other software falls or may fall into the "security risk"
> category tomorrow ... So best practice is probably still: Do not
> install any software, you do not need (at least on servers ;-)) ...
I don't think that's off-topic at all. In fact, I think it's the crux
of the argument you're trying to make: that the pkg* tools are a
better way to enable or disable software than any tool (such as
svcadm) that's designed for enabling or disabling software features.
I disagree. Besides the uneasy problems of inaccurate and missing
package dependencies[1] and patch havoc[2], the core issue is that
removing the software doesn't remove the security risk. As long as
users are still able to create files and set the execute permission
bits, users can recreate those applications whenever they want. It's
at best security-by-obscurity.
If the real concern here is security, then I would suggest limiting
the privileges(5) granted to users, roles, and subsystems such that
they just _can't_ do the things you don't want them doing.
If the real concern is that Sun ships a few programs that are setuid
or setgid, then you should address that concern with your support
folks. Sun has extensive security tools and practices in this area
that are designed to limit the number of such applications and to
review and audit the ones that are.
(Neither xterm nor sendmail are setuid, though sendmail is setgid to
its own separate group. I'm not sure what the "who knows" part refers
to; it's not as if Sun ever takes a "who knows" approach to security
in any software it ships.)
Also, don't forget that other solutions (such as Domains, LDoms and
Xen) may be more appropriate for some situations. That's why there's
more than one solution in this space.
As for the experience issue, I don't think it's entirely safe to
assume that those suggesting the use of 'svcadm' are just
inexperienced.
1. Core Solaris software tends not to have a complete list of
dependencies in the packaging database. Instead, testing relies
on the supported metaclusters (reduced networking, core, user,
developer, entire distribution). If you add or remove packages,
you have to be very careful to get the dependencies right.
2. Patch havoc can occur when you remove a package, patch the system,
and then later realize that you need to add a removed or new
package to the system -- because, for example, some user has a
legitimate need for one of the applications that were excluded.
The patching system skips over packages that are not present at
the time the patch is applied. It doesn't "remember" what changes
it would have made if the package had been present. If you later
install a package, that newly-added package won't have the same
patches as applied elsewhere on the system, leading to
inconsistent operation or just plain failure.
The only safe thing to do is to back out every patch that applied
to the package in question, add the package, and then reapply all
of the patches.
--
James Carlson, KISS Network <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
