On Sat, 2003-03-08 at 08:02, Jack Coates wrote: > 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 :-)
Virgin? > ... > > 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.
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
