On Thu, Aug 20, 2015 at 03:24:02PM -0700, Bryce Harrington wrote:
On Thu, Aug 20, 2015 at 03:04:32PM -0400, Martin Owens wrote:
> On Thu, 2015-08-20 at 12:01 -0700, Josh Andler wrote:
> > I think a simple system like that could be beneficial. Given the info
> > about it and my lack of knowledge of OSUOSL's systems, is our web
> > hosting on an encrypted filesystem?
> Not as far as I know. But an encrpyted sqlite3 db should be possible
> with an fs mount If I remember how ubuntu used to do home directory
I'll point out we already have a gpg/git-based password management
system. I'll be happy to add anyone to it that needs access, and while
I know gpg can be kind of technically complicated, I did attempt to
document it well enough that most steps should be pretty
Given that, I'd only want to consider switching the system if the new
one is a) properly open source, b) at least as secure as our current
system, and c) *technically* better in some way (apart from usability).
Bonus points for being user friendly.
I would add d) "is more or equally simple in implementation".
With that said, and not having actually played with Rattic, (a) seems
be covered since it's GPL licensed. (b) it is essentially sidestepping
by leaving it to the webserver and filesystem to handle (which actually
is probably a smart approach); however it feels like I'm comparing
apples to oranges so I'd want to hear the evaluation of an actual
security expert (e.g. Kees Cook) before deciding this one. As to (c),
it looks like it'll handle everything our current approach does, and
adds Auditing which our current system does *not* do, and which I do
think would be useful. Unfortunately they don't post screenshots of the
app itself, but presumably nearly anything would be more user friendly
than command line gpg so I'll concede that point.
Given A and C, I see no reason not to go ahead and set up something we
can try out. I'd want B settled before we migrate to it though.
In terms of priority, since we do have a system for handling passwords
right now, I don't see this as urgent, myself, but if Martin is gung ho
to experiment with it, I don't see a reason not to.
I *would* like to see a listing of what passwords we'd put in it, and
who should have access.*
* - Mostly because if there's anything our current system is missing,
then I should make a priority to fix that ASAP.
If this is for shared password management, I would actually argue for
eliminating the need for shared passwords entirely. How does revocation
currently work? Right now, I imagine you're sharing credentials instead of
having a credential for each person, which then has authorizations tied
to that credential. For example, give each admin an account (separate
credentials), and access to a sudo group (authorization tied to their
I suspect my lack of context here means something about your requirements
make this suggestion unworkable, though. :)
Kees Cook @outflux.net