On Sat, 2003-03-08 at 07:08, Pierre Fortin wrote: ... > > buckled tighter than NORAD. > > Funny you should mention NORAD... from '64 to '71, I worked in NORAD HQ > (Canada) deep under the mountain... so I have my own opinions about how > thight NORAD is... can't say any more... :> >
I actually struggled for a while trying to think of something that says "security" but actually means it... Fort Knox, a bank, WOPR, oh well :-) ... > Just confirms my "matrix" comment above... I could keep myself safe in a > hermetically sealed box; but would die from lack of oxygen... security > should *protect* a system, not kill its functionality, or worse lower the > user's choice of security... My point is that it's not up to the distros > to define the rules, rather provide the tools and some guidelines. If > msec was better thought out, it would probably be able to let us select > security levels on all the individual components instead of a matrix of > predefined settings. the matrix idea requires the administrator to first learn the matrix, second agree or disagree with it, and third make adjustments in perm.local. Absence of a matrix requires the administrator to make all the decisions from scratch. Using the matrix makes your mistakes less likely and the distro's mistakes more dangerous, not using the matrix puts you in full control instead of the distro. You say tomayto, I say tomahto on the theory here, but I do agree that there are issues with the practice -- especially in levels 4 and 5. I actually don't find this situation much different than configuring Tripwire. You can build your own policy file from scratch, or you can start from one of the templates. If you change policy to a new, less restrictive template, it isn't going to remember how you used to like it. > > I would check the msec docs; but I removed msec... begs the orthogonal > question: why aren't docs, man pages, info pages, etc. grouped into > (general, sysadmin, security, other_major_grouping} and installed > separately? That way, a user could make an informed decision before > installing a package... > that's what the web is for :-) > > Now, in your recommendation user must wipe the disk and start over from > > scratch. > > Huh? I don't follow your logic here... I only asked that msec not > blindly lower established security -- please elaborate... If the msec tool can't lower established security, then the user has no way to move from level 4 of the matrix to level 3 except by starting over. Msec can't distinguish between changes you made and changes it made until the Unix file and permissions system is very different than it is today (think HFS forks). So if you don't permit msec to make things more permissive, you can't choose to fix overly restrictive mistakes in a sweeping, matrix-thinking compliant way. You can certainly go through the whole system manually tweaking things, but in the instance of /proc restrictions, resource restrictions and kernel capabilities that manual tweaking is beyond the average administrator and more time-consuming than a re-install. > > > In msec's current implementation, user simply alters the security level > > to 3 and the system heals itself (in theory). > > But not in practice... it makes the system more vulnerable than what *I* > decided on... I'm beginning to think that Mdk should make their security > tools optional until those tools have been confirmed NOT to lower security > if installed/used... or worse, cut off its raison d'etre in msec >= 4... > If you don't want it to do things for you, then you should remove it and take responsibility for configuring your own security policy. It's a tool for helping admins decide and implement policy -- you don't have to use their matrix, and it isn't going to complain if you replace all the perm.* files with your own idea of how things ought to be. I have other things to do, unfortunately, so I pick a level that seems to work okay, make a few tweaks, nmap and nessus it, then keep up with the patches. Obviously you do something of the same nature because you're on Mandrake instead of a DIY distro like Slackware or LFS, right? To call for removal of a tool because you don't like it seems a little extreme (though I'm sure I've been guilty of it too). > I know this sounds a little 'off the wall'; but I still think msec is > ill-conceived... my 8.1 page on msec showed that the core idea is a > matrix and the system's security relies on the matrix being completely > filled in (http://pfortin.com/Linux/permresults.shtml) -- I don't see how > what I'm suggesting could be implemented in the current incantation, > beyond bad hacks... time for a new tool...? > I think that's being extreme, see above comments about editing the matrix. If you use the matrix-based tool, you've got to configure it properly. If you don't want it to increase permissions on something, you've got to tell it so through the only interface it's going to listen to -- rewriting it to never increase permissions will damage existing functionality without adding value (since the thing you want can be done on a specific basis with current tools by editing the matrix files). Obligatory note: this being open source, you can always create pfsec to act like you want it to: just be sure to clearly document that there is no going back after increasing the security level, or else you're going to have some unhappy users. -- Jack Coates Monkeynoodle: A Scientific Venture...
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
