3 ms·
Be sure to read this comment [0] alongside it. My feeling is this sort of document is fine to dip into it as a guide, and select what makes sense to you, but it
by isostatic 8y ago
Be sure to read this comment [0] alongside it. My feeling is this sort of document is fine to dip into it as a guide, and select what makes sense to you, but it feels very 'depth first'. It goes to extreme lengths to stop people using a computer, and neglects that fact people will simply bypass this and do their own thing anyway. The typical IT-first 'enterprise' solution to that is disciplinarys etc. Very few companies are (or should be) run by enterprise IT departments.
If you have to implement half the suggestions they make, you're probably doing it wrong. If you're that paranoid about giving a user access to a computer, you shouldn't give them access, not jump around locking down their access to bash once they are on there.
While the attitude of people who believe these documents still exists (in a few companies), people will simply avoid enterprise IT. A far better solution would be "sure, use ubuntu, just ensure that you install this package (which does a few sensible things -- syslog, package version reporting, etc)
[0] https://news.ycombinator.com/item?id=17654658 https://news.ycombinator.com/item?id=17654658
- wink 8y agoHad this exact discussion today :) party a said: let people read it and be educated party b said: let's install OpenSCAP[0] and get some reporting That said, I didn't mean to say "this is awesome, do it like they say" - but I'd definitely liberally use some parts of it if I were to write such a doc for my org. I'm not with BigCos usually so I'm no fan of clamping down root access, etc. I think developers basically need admin access on their machines except at the scale of Google where you have a dedicated force of people just caring for the tooling and that everyone can actually work instead of filing "please install libbzip2" tickets... [0]: https://www.open-scap.org https://www.open-scap.org