On 06/24/11 16:00, Shawn Walker wrote:
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.
That is an interesting idea. There are cases where uninstalling
something changes the security posture of the system - say uninstalling
a package containing firewall rules.
I suppose it depends on how much 'trust' you want to delegate to a user.
Indeed. I think having uninstall be a separate authorisation is useful.
For example, if we could delegate just 'pkg update' that would mean they
could only update installed packages -- not install arbitrary new ones.
That would be nice.
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.
Yes, I'm convinced that we have three distinct authorisations here:
solaris.pkg.install
solaris.pkg.update
solaris.pkg.uninstall
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.
Now that would be very cool! Even cooler would be if we got Audit
records not just the 'pkg history' but that is a discussion for another
day - both have value IMO.
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?
If you have 'solaris.pkg' I think you should be able to do that one.
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.
Great!
--
Darren J Moffat
_______________________________________________
security-discuss mailing list
[email protected]
