On Thu, 2007-08-23 at 12:20 +0100, Darren J Moffat wrote:
> Bill Sommerfeld wrote:
> The authorisation protecting the cleartext password isn't one that most 
> admins would have as I understand this case.   Also it requires the 
> admin to be running svcprop on this service while having that 
> authorisation - quite a bit different than "can you look in this file". 

Except that in most small sites, there will be one admin, and they'll
either be administering as root or will have the authorization.  (And,
being involved with backup, they'll probably also have authority to read
every file on the system, so "can you look in the file" remains a
concern).

> Also if the password is obscured in the SMF repository then a tool to 
> generate that obscured format will be needed (either a new tool or 
> documentation on how to use an existing one).  Also this means that 
> practically every user of this SMF functionality is going to need a 
> similar tool.

We said just as much in the 2007/177 opinion; the project team for
2007/177 opted to leave additional protections for secrets in SMF to
applications rather than putting them 

> In my opinion we have much much bigger "sins" in Solaris already, for 
> example the ssh host keys are in the clear, IPsec private keys are 
> usually in the clear.   as-is

We generally hold new work to higher standards than old.  This is no
different.  In particular, the bulk of "sins" you cite occurred
before      
     http://sac.eng/cgi-bin/bp.cgi?NAME=passwords-storage.bp
became effective in 2004.

What's more, RSA private keys are not subject to shoulder-surfing
attacks like passwords are; RSA keys large enough to be secure are too
large to be memorized by the vast majority of people.

> Personally I think this case has done enough and it is either time to 
> let it complete or for it to be derailed and have a vote called (I'm not 
> willing to derail it).

I believe that there isn't enough wiggle room in the password storage
best practice to allow us to approve the case without having at least a
lame reversible obfuscation (such as base64 encoding) applied to the
passwords before storing them in SMF.

Reply via email to