Re: [expert] msec fixed in 9.1?
On 07 Mar 2003 19:56:21 -0800 Jack Coates [EMAIL PROTECTED] wrote: On Fri, 2003-03-07 at 17:25, Pierre Fortin wrote: ... In this case, I *want* 700... no sane automated security system should ever *reduce* security levels setup by the owner... it's downright nasty IMNSHO... ... rant msec should check existing permissions when run; if they are tighter than what would be set, LEAVE THEM ALONE *AND* RECORD the settings as the MINIMUM for the current level -- in other words, if /home/* are 700 at level 3, the user tries level 4, and goes back to 3, the perms should still be 700! NEVER EVER reduce security levels set by the owner! It's downright irresponsible... and NO, telling the users to add local rules after lower their security is not acceptable -- fix the logic! /rant I do agree with you, but I also see Mandrake's point and I think that this comes from several distros of telling people that a workstation OS clearly not intended as a server should be using levels 4 and 5 and 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... : Anyway... I have no problems with suggesting higher security levels... what I *DO* have a problem with is lowering security JUST-TO-MATCH-SOME-PREDEFINED-MATRIX... If several distros think a w/s OS should be tighter than a server, then they have missed the boat... IMO, yes w/s OS should be tight; but server OS should be tighter *without* killing _its_ raison d'etre... User installs system, user follows installer recommendation and chooses level 4. User spends several days trying to make Level 4 work before realizing that msec is the problem. 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. 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... 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... 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... 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...? Pierre Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec fixed in 9.1?
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
Re: [expert] msec fixed in 9.1?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On March 7, 2003 19:33 pm, Pierre Fortin wrote: On Fri, 7 Mar 2003 12:09:20 -0600 (CST) J.P. Pasnak [EMAIL PROTECTED] wrote: Pierre Fortin said: SIGH... I recently noticed that all my users' home directories had 755 permissions... changed this to 700 and now it's back to 755... What's the point of separate userids if msec allows each user to read another's directory?? Will there be a more secure default in 9.1...? If not, then I don't care to continue with msec on my systems: rpm -e msec chmod 700 /home msec works exactly as it should, and I doubt they will change the defaults because of people not knowing how to use it. Learn how to edit '/usr/share/msec/perm.x' or create a custom permission file with drakperm. Also, read this article: http://www.mandrakesecure.net/en/docs/msec.php See also the rant inside my reply to Jack... gratuitously lowering owner-defined security levels is irresponsible... trying to shift the blame to the owner with local rules doesn't cut it I made my local rules EXplicitly when I made /home/* 700... Blindly lowering them, without even asking BTW, is a security violation IMO OK, I see your point here, but how would you go about implementing this? Would msec have to do comparisons on all directories, increasing completion time and usage? Would it have on/off per directory functionality? I like msec, and have over time worked around it's quirks, so I'd like to see it improved rather than chucked out... - -- Live fast, die young, you're sucking up my bandwidth. - -- J.P. Pasnak, CD CCNA [EMAIL PROTECTED] http://www.warpedsystems.sk.ca Kernel version: 2.4.21-0.13mdk Current Linux uptime: 1 hour 19 minutes. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+ahQ+BMRgzmzdk08RAm2PAKDBTpYf+QpQFAzlq3/PHMgQ1dZPWQCgu1se E+tXQwGObMMosh+kNwtM5NE= =IQHG -END PGP SIGNATURE- Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec fixed in 9.1?
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
Re: [expert] msec fixed in 9.1?
On Sat, 8 Mar 2003 10:03:07 -0600 J.P. Pasnak [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On March 7, 2003 19:33 pm, Pierre Fortin wrote: On Fri, 7 Mar 2003 12:09:20 -0600 (CST) J.P. Pasnak [EMAIL PROTECTED] wrote: Pierre Fortin said: SIGH... I recently noticed that all my users' home directories had 755 permissions... changed this to 700 and now it's back to 755... What's the point of separate userids if msec allows each user to read another's directory?? Will there be a more secure default in 9.1...? If not, then I don't care to continue with msec on my systems: rpm -e msec chmod 700 /home msec works exactly as it should, and I doubt they will change the defaults because of people not knowing how to use it. Learn how to edit '/usr/share/msec/perm.x' or create a custom permission file with drakperm. Also, read this article: http://www.mandrakesecure.net/en/docs/msec.php See also the rant inside my reply to Jack... gratuitously lowering owner-defined security levels is irresponsible... trying to shift the blame to the owner with local rules doesn't cut it I made my local rules EXplicitly when I made /home/* 700... Blindly lowering them, without even asking BTW, is a security violation IMO OK, I see your point here, but how would you go about implementing this? Would msec have to do comparisons on all directories, increasing completion time and usage? Would it have on/off per directory functionality? I like msec, and have over time worked around it's quirks, so I'd like to see it improved rather than chucked out... ^^^ Ditto... my whole point although probably not stated/understood as intended... L8R. Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec fixed in 9.1?
On Sat, 2003-03-08 at 08:30, Pierre Fortin wrote: ... 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'm clearly not understanding what you're trying to say then -- I'm not following the spreadsheet comments at all. 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... : cool gadget :-) ... -- Jack Coates Monkeynoodle: A Scientific Venture... Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec fixed in 9.1?
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
Re: [expert] msec fixed in 9.1?
On 08 Mar 2003 08:47:28 -0800 Jack Coates [EMAIL PROTECTED] wrote: On Sat, 2003-03-08 at 08:30, Pierre Fortin wrote: ... 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'm clearly not understanding what you're trying to say then -- I'm not following the spreadsheet comments at all. msec is a matrix, like a s/s... the problem is that only one column (level) is active at a time... moving from one level to another is like moving between columns... only way to shift cells on a per row basis is to write Python code... Look at it another way... imagine a webmin page with N columns (5 initially) and M rows (one per msec rule)... some rules can be handled by selecting a level with a radio button; others might use an option list. Others might need text input... whatever... the idea is that each row (function/rule) can individually be customized, rather than the present throw the master switch to position N we have now... Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
[expert] msec fixed in 9.1?
SIGH... I recently noticed that all my users' home directories had 755 permissions... changed this to 700 and now it's back to 755... What's the point of separate userids if msec allows each user to read another's directory?? Will there be a more secure default in 9.1...? If not, then I don't care to continue with msec on my systems: rpm -e msecchmod 700 /home Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec fixed in 9.1?
On Fri, 2003-03-07 at 09:23, Pierre Fortin wrote: SIGH... I recently noticed that all my users' home directories had 755 permissions... changed this to 700 and now it's back to 755... What's the point of separate userids if msec allows each user to read another's directory?? Will there be a more secure default in 9.1...? If not, then I don't care to continue with msec on my systems: rpm -e msecchmod 700 /home [EMAIL PROTECTED] jack]$ grep home /usr/share/msec/perm.* | grep 755 /usr/share/msec/perm.0:/home/ root.root 755 /usr/share/msec/perm.0:/home/* current 755 /usr/share/msec/perm.1:/home/ root.root 755 /usr/share/msec/perm.1:/home/* current 755 /usr/share/msec/perm.2:/home/ root.root 755 /usr/share/msec/perm.2:/home/* current 755 /usr/share/msec/perm.3:/home/ root.root 755 So run in 4 or 5 and suffer the problems there, or fix it in /etc/security/msec/perm.local with /home/* current 700 It's probably 755 so that you won't get annoying no permissions pop ups when navigating your filesystem with a GUI filemanager. I agree that it should be 750 (group membership is a good thing), but removing the msec tool is analogous to turning off the firewall instead of reconfiguring it because it doesn't let you do something. Of course, lots of people on this list seem to do that to, so who am I kidding :-) Reminds me of that quote about how Unix won't stop you from hurting yourself if that's what you really want to do. Interestingly enough, that same command on another MDK9.0 system gives another two perm levels: /usr/share/msec/perm.4:/home/ root.adm 751 /usr/share/msec/perm.4:/home/* current700 /usr/share/msec/perm.5:/home/ root.root 711 /usr/share/msec/perm.5:/home/* current700 The first machine was upgraded from 8.2, the second was a clean install of 9.0. -- Jack Coates Monkeynoodle: A Scientific Venture... Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec fixed in 9.1?
Pierre Fortin said: SIGH... I recently noticed that all my users' home directories had 755 permissions... changed this to 700 and now it's back to 755... What's the point of separate userids if msec allows each user to read another's directory?? Will there be a more secure default in 9.1...? If not, then I don't care to continue with msec on my systems: rpm -e msecchmod 700 /home msec works exactly as it should, and I doubt they will change the defaults because of people not knowing how to use it. Learn how to edit '/usr/share/msec/perm.x' or create a custom permission file with drakperm. Also, read this article: http://www.mandrakesecure.net/en/docs/msec.php -- Live fast, die young, You're sucking up my bandwidth. J.P. Pasnak, CD CCNA http://www.warpedsystems.sk.ca Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec fixed in 9.1?
On 07 Mar 2003 09:42:49 -0800 Jack Coates [EMAIL PROTECTED] wrote: Jack, Thanks for the info... but I just gotta rant about msec... : On Fri, 2003-03-07 at 09:23, Pierre Fortin wrote: SIGH... I recently noticed that all my users' home directories had 755 permissions... changed this to 700 and now it's back to 755... What's the point of separate userids if msec allows each user to read another's directory?? Will there be a more secure default in 9.1...? If not, then I don't care to continue with msec on my systems: rpm -e msecchmod 700 /home [EMAIL PROTECTED] jack]$ grep home /usr/share/msec/perm.* | grep 755 /usr/share/msec/perm.0:/home/ root.root 755 /usr/share/msec/perm.0:/home/* current 755 /usr/share/msec/perm.1:/home/ root.root 755 /usr/share/msec/perm.1:/home/* current 755 /usr/share/msec/perm.2:/home/ root.root 755 /usr/share/msec/perm.2:/home/* current 755 /usr/share/msec/perm.3:/home/ root.root 755 So run in 4 or 5 and suffer the problems there, or fix it in /etc/security/msec/perm.local with /home/* current 700 It's probably 755 so that you won't get annoying no permissions pop ups when navigating your filesystem with a GUI filemanager. I agree that it should be 750 (group membership is a good thing), but removing the msec tool is analogous to turning off the firewall instead of reconfiguring it because it doesn't let you do something. I removed shorewall for several reasons -- mainly cuz it killed everything without ever letting me know it was in the picture... Of course, lots of people on this list seem to do that to, so who am I kidding :-) Reminds me of that quote about how Unix won't stop you from hurting yourself if that's what you really want to do. In this case, I *want* 700... no sane automated security system should ever *reduce* security levels setup by the owner... it's downright nasty IMNSHO... Interestingly enough, that same command on another MDK9.0 system gives another two perm levels: /usr/share/msec/perm.4:/home/ root.adm 751 /usr/share/msec/perm.4:/home/* current700 /usr/share/msec/perm.5:/home/ root.root 711 /usr/share/msec/perm.5:/home/* current700 The first machine was upgraded from 8.2, the second was a clean install of 9.0. Interesting... mine was upgraded from 8.2 and another was fresh installed -- both get changed to 755... rant msec should check existing permissions when run; if they are tighter than what would be set, LEAVE THEM ALONE *AND* RECORD the settings as the MINIMUM for the current level -- in other words, if /home/* are 700 at level 3, the user tries level 4, and goes back to 3, the perms should still be 700! NEVER EVER reduce security levels set by the owner! It's downright irresponsible... and NO, telling the users to add local rules after lower their security is not acceptable -- fix the logic! /rant Anyway, I take it this will still happen in 9.1? Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec fixed in 9.1?
On Fri, 7 Mar 2003 12:09:20 -0600 (CST) J.P. Pasnak [EMAIL PROTECTED] wrote: Pierre Fortin said: SIGH... I recently noticed that all my users' home directories had 755 permissions... changed this to 700 and now it's back to 755... What's the point of separate userids if msec allows each user to read another's directory?? Will there be a more secure default in 9.1...? If not, then I don't care to continue with msec on my systems: rpm -e msecchmod 700 /home msec works exactly as it should, and I doubt they will change the defaults because of people not knowing how to use it. Learn how to edit '/usr/share/msec/perm.x' or create a custom permission file with drakperm. Also, read this article: http://www.mandrakesecure.net/en/docs/msec.php See also the rant inside my reply to Jack... gratuitously lowering owner-defined security levels is irresponsible... trying to shift the blame to the owner with local rules doesn't cut it I made my local rules EXplicitly when I made /home/* 700... Blindly lowering them, without even asking BTW, is a security violation IMO It's like your favorite car dealer deciding to replace all the locks and ignition switches so they're all keyed the same It's not acceptable IMO to lower security simply because the msec coder is too lazy to do the Right Thing! Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec fixed in 9.1?
On Fri, 2003-03-07 at 17:25, Pierre Fortin wrote: ... In this case, I *want* 700... no sane automated security system should ever *reduce* security levels setup by the owner... it's downright nasty IMNSHO... ... rant msec should check existing permissions when run; if they are tighter than what would be set, LEAVE THEM ALONE *AND* RECORD the settings as the MINIMUM for the current level -- in other words, if /home/* are 700 at level 3, the user tries level 4, and goes back to 3, the perms should still be 700! NEVER EVER reduce security levels set by the owner! It's downright irresponsible... and NO, telling the users to add local rules after lower their security is not acceptable -- fix the logic! /rant I do agree with you, but I also see Mandrake's point and I think that this comes from several distros of telling people that a workstation OS clearly not intended as a server should be using levels 4 and 5 and buckled tighter than NORAD. User installs system, user follows installer recommendation and chooses level 4. User spends several days trying to make Level 4 work before realizing that msec is the problem. Now, in your recommendation user must wipe the disk and start over from scratch. In msec's current implementation, user simply alters the security level to 3 and the system heals itself (in theory). -- Jack Coates Monkeynoodle: A Scientific Venture... Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec fixed in 9.1?
On Fri, 2003-03-07 at 19:56, Jack Coates wrote: ... I do agree with you, but I also see Mandrake's point and I think that this comes from several distros of telling people that a workstation OS clearly not intended as a server should be using levels 4 and 5 and buckled tighter than NORAD. BTW, the above is irony, vis a vis recent threads on support policy and EOL and announcement of MandRHake Advanced Server 2.1. -- Jack Coates Monkeynoodle: A Scientific Venture... Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
