On 06/24/11 04:06, Darren J Moffat wrote:
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:
I have a few brief comments to your proposal; my responses are not
exhaustive:
solaris.pkg.install
Allow installation and update of packages including creating
a new BE if required.
I'm assuming this also covers fix, revert, and uninstall?
solaris.pkg.facet
solaris.pkg.variant
Set or change a variant or facet
Setting and changing variants actually changes the content of installed
packages so it can trigger the creation of boot environments, etc. which
mean zfs filesystem creation and so forth. I realise that doesn't
prevent it from being a separate authorisation, but I wanted to point
that out.
I'm also in the process of implementing "mediated links" [1], which are
similar in nature to facets/variants, so that would need one of these too...
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.
With the current architecture of the package system, a user that can
install or uninstall packages or change configuration must have the
physical ability to read and write to all of /var/pkg. (Maybe not
themselves, but certainly the pkg process.)
-Shawn
_______________________________________________
security-discuss mailing list
[email protected]
