James Carlson wrote:
> Glenn Brunette writes:
>> That is a non-starter for many of our customers who are looking for
>> unique credentials for each of their services -- especially those
>> that may be running under the same OS instance/zone. Not only does
>> this help with accountability (syslog and audit) but having unique
>> credentials will also help contain a compromise should one
>> (unprivileged) service be exploited. If you were running apache and
>> mysql (for example) as the same UID, a flaw (w/arbitrary code execution)
>> in one could lead to the direct compromise of the other running service.
>> Taking away proc_session from each service could help with this however.
>
> Yes, I think LP is a better answer for limiting damage due to code
> flaws.
I think that a combined approach is really the best answer here (as Nico
mentioned). This is not just a matter of engineering and deployment,
but also one of security validation. It is much easier for our
customers to validate the isolation of applications by UID as compared
with having to verify that LP was properly configured (throughout the
lifetime of the system/service).
I believe quite strongly in an approach where you have:
* unique uids and gids for "different" services. The benchmark for
determining whether something is different is based on its security
boundary as well as the requirements of the application
* running service with reduced privileges (via SMF or by being made
to be privilege aware). Of these two options, SMF is easier for
a customer to audit but privilege aware services have much greater
flexibility to limit what is run with privilege
add to this running the services in a hardened (SBD), sparse-root non-
global zone and you have something that has a very strong foundation
for service delivery. Additional tuning/tweaks will always be needed
in one form or another, but just having these four things is a huge
improvement from where many are today.
> The apache and mysql examples might not be the best ones -- those are
> cases where you do have related file permissions, and you'll probably
> want a UID just for that.
We can also find examples and counterexamples to support these claims,
but if we look at this in light of some of our key focus areas, you will
find that more often than not separate UIDs are preferrable. This has
been true for much of our traditional customers for quite some time
(especially in financial services, government, telco/media, etc.) as
well as for the web-scale architectures many of our newer customers are
building today.
g
