On 08 Mar 2003 08:02:07 -0800 Jack Coates <[EMAIL PROTECTED]> 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 :-) > ...
In this super-connected world, it's hard to give analogies without "walking into it"... LOL > > 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. I have no problem with a matrix; but this is like only being able to select a column in your spreadsheet, not a row or individual cell... I have not been able to find the dependency failure (installed everything related AFAIK) to be able to compile http://kaptain.sourceforge.net; otherwise, I'd probably have coded a visual (1/2 way between the GUI/CLI argument :) interface to msec and other stuff... at my age, I prefer prototyping tools and then let the young 'uns code for speed... :> > 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. All or nothing approach which is the problem IMO. > > > > 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 :-) and that's really easy for a newbie on a new install that won't connect... :> > > > 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. Again... spreadsheet: all, column, row, cell... > > > > > 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). Correction... *I* remove it... I called for "optional" until it's made smarter... I don't recall calling for its removal... > > 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. You're making assumptions... 'nuf said... :) Gotta go... L8R...
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
