On Mon, Mar 19, 2007 at 08:56:07AM -0800, Gary Winiger wrote: > > 2.1.1. Definition > > > > The read_authorization property may optionally be added to any > > property group of type application (SCF_GROUP_APPLICATION). It is > > Why should it be restricted to only application PGs at this time? > What's the drawback of being general?
I don't think this has any sensible meaning with respect to the other property group types, which contain information, broadly speaking, about the SMF representation and state of the service. Application groups are inherently different; they contain information used by the underlying implmentation of the service. Given the purpose of the former, a huge number of failure cases (both present and future) must be anticipated if we permit structural property groups to be marked sensitive; I don't see a benefit that would justify the amount of complexity that would introduce. > > 2.3. svcprop(1) changes > > > - If no property or property group was specified, properties for > > which the user lacks appropriate authorization to read will be > > displayed as if they had zero values. > > Are string values the empty string? All properties with no values show up as the empty string; i.e., svc:/network/nis/client:default> addpg foo application svc:/network/nis/client:default> setprop foo/bar = integer: () svc:/network/nis/client:default> listprop foo/bar foo/bar integer ... root at fallout:~ # svcprop -p foo/bar nis/client:default root at fallout:~ # So yes. > > 2.4. svccfg(1M) changes > > > > 2.4.1. export changes, introduction of exportall > > > > 'svccfg export' is modified to export the values of properties in > > SPGs as if they had no values, regardless of whether the user performing > > the operation has the required authorization. This prevents accidental > > exposure of sensitive data in XML documents used for interchange > > purposes. > > I believe this needs guidance in the SMF policy. If you use > read_authorization properties, the manifest should not initialize > the default value to anything sensitive. Agree. > > To provide the ability to export documents containing the values of > > sensitive properties, we introduce 'svccfg exportall'. This command > > behaves identically to 'export', except that the values of properties in > > SPGs are exported if the user has sufficient authorization to read them. > > Otherwise, the command terminates and displays an appropriate error > > message. > > Does it terminate at the first SPG, or will it always terminated > just in case there may be an SPG in the repository even if there > are none? It will abort only if an SPG is encountered for which the user does not have sufficient authorization to read its contents. > Additionally I believe the policy needs to be updated. > It should outline the form. VIZ. > solaris.smf.read.cioppino > And as noted above guide against putting sensitive values > in the manifests as they are (at least today) publically readable. Agree. I'll add diffs to the policy to this effect. > How does the repository protect sensitive values from view? svc.configd(1M) already has checks for adequate priviliges and authorizations for add/modify/delete transactions. I'm adding similar checks to the code path that returns property values. This seems like implementation details, though; I can provide a webrev in a couple of days if you want the nitty-gritty. > What requirements does this place on remote repositories? Since the interface between svc.configd and a remote backend is not defined by any case I've found, it's difficult to be sure. To prevent privilege escalation, a remote repository storing SMF data would already need to prevent changes to its contents by unauthorized users (and the administrator thereof must ensure that authorization to change the contents is granted only to those who would be authorized to do so on the affected hosts). This change requires the same capability with respect to reads. The most likely future networked backend, LDAP, already offers this capability. > Have the NSS2/Sparks folk been included in any new remote > repository requirement? I don't see anything in the Sparks (nor Duckwater) materials to suggest that they're considering implementing networked backends for SMF. If I've overlooked something here, please let me know. -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!"
