Bill Sommerfeld wrote:
> No, it's not closed.  See my message dated 15 Aug 2007 10:51:39 -0400; 
> the current password-in-files policy says that if you're storing a
> password you need at the very least some sort of reversible obfuscation
> to protect against shoulder-surfing-the-admin attacks.

While I appreciate the shoulder surfing the admin attack I think in this 
case the risk of that is pretty small compared to other cases.  On the 
other hand the password we are talking about here is near root 
equivalent, since it allows access to backup the machine, so it 
shouldn't be dismissed to easily.

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". 
  My understanding of this case was that the authorisation is mostly 
intended to be given to the user account that the ndnmp service run as 
rather than an admin.

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.

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.  Those are in separate files but I don't see how 
that really helps much, it is basically cat vs svcprop.

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).

-- 
Darren J Moffat

Reply via email to