On 06/24/11 10:08, Philip Brown wrote:
Bart Smaalders wrote:
We've been discussing this idea for some time.
From a risk perspective there seem to be three classes of
packaging operations:
1) safe, non-modifying operations that anyone can run today.
pkg list, pkg info, pkg facet, ...
2) installing or tailoring (via facets/variants) software from
existing (presumably trusted) publishers with existing repositories.
3) modifying image properties, publishers, signing requirements, etc.
Anyone allowed 3) is capable of becoming root via many obvious and
un-obvious attack vectors (installing setuid shell from private
publisher, for example).
perhaps there could be a role with privileges of,
"Install packages, with the exclusion of packages that install setuid,
or install binaries to [excluded path list]"
additionally, it could be allowable "install the package, but do not
enable the setuid bit."
Since there are some software packages that give "enhanced" operation if
setuid root, but still provide benefit without it.
We don't want to be in a scenario where one administrator installs the
package and files delivered are silently setuid, but another installs
them and they're setuid. That's bad.
The package system must deliver bits as defined in packages. That is
what allows the packages to be verified and repaired by the
administrator in a consistent fashion.
*However*, package creators can deliver both the non-setuid and setuid
versions using variants:
set name=pkg.fmri [email protected]
file path=/usr/bin/foo ... mode=2555 variant.setuid=true
file path=/usr/bin/foo ... mode=0555 variant.setuid=false
That allows the package creator explicitly support changing setuid, and
the administrator have a verifiable/repairable system.
All a user would have to do then is:
pkg set-variant setuid=(true|false)
pkg install foo
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
