> > > I'm not comfortable with mixing sensitive properties into the main
> > > property database - in the past, my advice to other projects (including
> > > the wifi folks) has always been to isolate sensitive properties into
> > > separate files so that we can in the future improve the protection of
> > > them without complicating access to non-sensitive fields.
Perhaps I'm miss remembering. I thought the wifi folk wanted
to have the unsentivive properties accessible to all through
a file of 644 permissions. Thus the WEP/WPA/ ... keys needed
to be kept elsewhere.
svc.configd is the arbritrator of the repository. The repository
is mode 600. I believe this is a difference between these cases.
> > >
> > > In addition, the recommendation in the "password storage" best practice:
> > > http://sac.eng/cgi-bin/bp.cgi?NAME=passwords-storage.bp
> > > is that passwords and similar sensitive values be encrypted when stored
> > > in the filesystem.
>
> FWIW, the password storage best practice is also published at:
> http://www.opensolaris.org/os/community/arc/bestpractices/passwords-files/
I believe this proposal is designed to meet the actual policy
as it would be applied to authorized use:
If a program must store a principal's reusable password on
a filesystem in order to automate future authentication
attempts, then the program must place the password in a file
which is readable only to the principal whose password is
stored in the file. The permissions of the file should grant
no access to either group or world.
The repository is 600 to root; svc.configd interprets
authorization as created by the administrator for access to
sensitive properties.
Now, the "Further, it is recommended ... encrypted ..."
is not actually met. One might consider derailing to write
an opinion that it is impossible for this case to provide
a *master* way of encrypting sensitive property values without
other technology (perhaps functional TPMs on all HW on which
Nevada will ever run) -- and a project to make TPMs and master
HW keys a requirement for Nevada be created.
I'm not sure that's valuable. What is probably far more
appropriate is to properly document the level of protection
given to sensitive properties and leave it to the reader/writer
of the property to provide greater protection as they see fit.
IIRC, as Greenline was approved, the spec included something
about properties being publically viewable and that any sensitive
values should be encrypted by the application.
This project corrects the publically viewable aspect.
Consider the analogy of when passwd(4) contained the unix
crypt values. The shadow(4) project made the unix crypt values
hidden from public read access. The application is still
responsible for creating and otherwise using the values
stored there.
I'm not sure why this project should be responsible for
doing more than it proposes. Yes, it would be great to
not rely on applications. I believe Solaris provides
insufficient means to not rely on the application.
Again, advice for a project to provide strong keying material
for hands off operation.
Gary..
