The idea behind this proposal is making Solaris "Software Installation"
RBAC profile more fine grained.
In some deployments it would be useful to have administrators that
can install only "blessed" software and updates but not to be able
to install any arbitrary software (say setuid binaries or config files
that give them more rights). In some use cases a linked image would be
appropriate for this but in others it is the system image we want to update.
For example allowing DBAs to update the database binaries without
requiring an OS administrator. Or allowing a class of administrator
that is allowed to apply OS vendor patches/updates but not to change the
system configuration.
The current "Software Installation" RBAC profile is basically root
equivalent because it allows installation of any arbitary software via
pkg(1).
With a few minor enhancements to pkg(1) this is actually fixable.
The pkg(1) command has three relatively distinct purposes:
1. Actual software installation and update
2. Policy for the image - wither signing is in use
what variants and facets to apply, where the publishers are.
3. Searching and information about packages. This
part generally needs no privilege to operate with.
If we could create an RBAC profile that allowed using pkg(1) to do just
the installation an update but not allow changing the image policy we
would be able to provide a "safe" use of pkg(1) that wasn't root equivalent.
By controlling which publishers are used we can ensure only "blessed"
software can be installed via pkg(1). Even more so if the image policy
has a requirement for signed packages.
To be able to do the installation pkg(1) needs to continue running as
uid 0 with all privilege. To provide the necessary separation between
image policy and installation the pkg(1) system can check RBAC
authorisations.
The default case needs to remain that someone running pkg(1) via sudo or
logged in as the root account/role is allowed to do anything - after all
they are root anyway. While still allowing delegated administration.
To implement this pkg(1) becomes RBAC authorisation aware - just like
SMF and passwd(1) etc.
A first cut at the possible break down of authorisations would be:
solaris.pkg.install
Allow installation and update of packages including creating
a new BE if required.
solaris.pkg.facet
solaris.pkg.variant
Set or change a variant or facet
solaris.pkg.publisher
Add or change publishers, including mirrors and requirements for
SSL
solaris.pkg.property
Allows changing (security sensitive) policy of the image such as
the signature-policy, ca-path.
[ The reason that 'solaris' is part of the prefix is because by default
the root user on Solaris has all authorisations in the 'solaris.*'
namespace ].
The current "Software Installation" profile will be updated so that
it provides the solaris.pkg.install authorisation but not any of the
others. A new RBAC profile named named "Software Installation Policy"
will be added that has solaris.pkg.{facet,variant,publisher,property"
but not solaris.pkg.install. This provides for a separation of duty
between those that define the policy and those that do the installation.
If a single user needs to do both they can be granted both RBAC profiles.
Implementation Notes
--------------------
Ideally the authorisation checks should be in the pkg.client.api or
pkg.client.image layers for the relevant actions. Unfortunatley though
some of the subcommands for pkg(1) are implemented in client.py
directly at this time. This means that there will be a mix of where
the authorisation checks will be done.
Since the majority of the pkg(1) code is python a python binding to the
libc`chkauthattr(3C) call.
The current calls to portable.os.is_admin() that are being used to
check for permission to modify the system image can be updated so that
is_admin() takes the authorisation name we need to check. For those
platforms that don't support Solaris RBAC authorisations they can have
have a different implementation or they can check their equivalent of
root (which is what portable.os.is_admin() does today on unix systems).
Some of the calls to pkg.client.image.lock may also be appropriate
places for an authorisation based check.
--
Darren J Moffat
_______________________________________________
security-discuss mailing list
[email protected]
