On 06/24/11 07:42, Darren J Moffat wrote:
On 06/24/11 14:57, Shawn Walker wrote:
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?
Probably should yes.
Actually, one thought that occurred to me was whether uninstall and
update should be separate.
I suppose it depends on how much 'trust' you want to delegate to a user.
For example, if we could delegate just 'pkg update' that would mean they
could only update installed packages -- not install arbitrary new ones.
Or as another example, maybe you trust them to install or update
packages, but you don't want them to be able to uninstall your auditing
software.
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.
Maybe there isn't value in them being separate authorisations and
they should just be grouped with solaris.pkg.install.
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...
Similarly maybe this should just be solaris.pkg.install. I don't want to
go overboard.
That seems best.
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.)
That is fine because the RBAC profile will be running pkg as euid=0 but
the code of pkg(1) will be checking if the real user is authorised to do
a specific operation.
I thought as much, thanks for confirming. To go along with this then,
pkg history could call getauid() and record the real user executing the
operation. That would help as far as an audit trail is concerned.
And on that subject, I'd assume that 'pkg purge-history' wouldn't be
something that anyone other than root could do, or would there be a
specific authorisation for that as well?
For a user that has solaris.pkg.install but not solaris.pkg.property
they won't be able to change the publishers so signing policy so they
won't be able to access packages in any publisher other than those
specified by a user that has solaris.pkg.property/solaris.pkg.publisher.
One install case I hadn't thought about before was installing from an
archive. Maybe archive installation needs to require solaris.pkg.install
and solaris.pkg.publisher ?
To put it more generically, "installing from a temporary source". The
-g option accepts *any* source of package data (including package
archives) so you could say -g http://some/random/repository.
And yes, as a result of installing from a temporary source it may alter
both publisher configuration and installed packages.
So it would make sense to require both of those authorisations.
-Shawn
_______________________________________________
security-discuss mailing list
[email protected]
