[expert] msec level 4
Good morning, I´ve got another msec question. I was working on a different computer on my lan and hadn´t put it´s id in my hosts file on my server yet. I was lazy and didn´t feel like getting on a system which had access (for ssh that is) so I was trying different toys to see which had access. I couldn´t get on user accounts using ftp, or ssh, etc, but then I tried telnet and got right in. I though, ´hmm, that´s odd...´ I´m also able to get in using my domain name - which I´m not able to do using ssh. I´m confused; why can I telnet get right in but ssh is blocked? I know the obvious answer - remove telnet from the server - but I would like more information about this before removing the symptom. Thanks -- Michael Holt Snohomish, WA (o_ [EMAIL PROTECTED](o_ (o_ //\ www.holt-tech.net(/)_ (/)_ V_/_www.mandrake.com ¨For we are God´s workmanship, created in Christ Jesus to do good works, which God prepared in advance for us to do.¨ Eph. 2:10 Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec level 4
On Sun, 26 Oct 2003, Michael Holt wrote: I´ve got another msec question. I was working on a different computer on my lan and hadn´t put it´s id in my hosts file on my server yet. I was lazy and didn´t feel like getting on a system which had access (for ssh that is) so I was trying different toys to see which had access. I couldn´t get on user accounts using ftp, or ssh, etc, but then I tried telnet and got right in. I though, ´hmm, that´s odd...´ I don't run telnet (naturally g), but I'd guess that access to it is probably controlled by xinetd, rather than by /etc/hosts.allow. If that's the case, you'll have an /etc/xinetd.d/telnet[d] file where this sort of thing can be configured. After you've made any changes to that file, the xinetd service would need to be restarted, for those changes to take. I´m also able to get in using my domain name - which I´m not able to do using ssh. I´m confused; why can I telnet get right in but ssh is blocked? I know the obvious answer - remove telnet from the server - but I would like more information about this before removing the symptom. I usually need to add a line like this to /etc/hosts.allow: sshd : ALL Or, alternatively, to limit access to only coming from the LAN: sshd : 192.168.0. Note the trailing dot. That syntax translates to 192.168.0.*. Be sure to urpme telnet-server sometime soon, though! ;) HTH! -- Bill Mullen [EMAIL PROTECTED] MA, USA RLU #270075 MDK 8.1 9.0 Microsoft has a new version out, Windows XP, which according to every- body is the 'most reliable Windows ever.' To me, this is like saying that asparagus is 'the most articulate vegetable ever.' -- Dave Barry Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec level 4
On Sunday 26 October 2003 09:33 am, Michael Holt wrote: Good morning, I´ve got another msec question. I was working on a different computer on my lan and hadn´t put it´s id in my hosts file on my server yet. I was lazy and didn´t feel like getting on a system which had access (for ssh that is) so I was trying different toys to see which had access. I couldn´t get on user accounts using ftp, or ssh, etc, but then I tried telnet and got right in. I though, ´hmm, that´s odd...´ I´m also able to get in using my domain name - which I´m not able to do using ssh. I´m confused; why can I telnet get right in but ssh is blocked? I know the obvious answer - remove telnet from the server - but I would like more information about this before removing the symptom. I would guess that something is either not configured correctly, you have installed some software that has changed the default settings, or you are hitting a different machine than you think you are hitting. I have tried this on my web server which is also set to msec level 4 and it does NOT work. Telnet connections are refused, just like SSH was initially until I opened that up using hosts.allow. It is possible that you have altered your hosts.deny file and the cron job that is supposed to change it back simply hasn't run yet, but it should get around to it. However, default at msec level 4 is to create a hosts.deny file that denies all. Until you explicitly allow connections in hosts.allow or remove hosts.deny, it should be refusing all connections. -- Bryan Phinney Software Test Engineer Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec level 4
Bill Mullen mused: I don't run telnet (naturally g), but I'd guess that access to it is probably controlled by xinetd, rather than by /etc/hosts.allow. If that's the case, you'll have an /etc/xinetd.d/telnet[d] file where this sort of thing can be configured. After you've made any changes to that file, the xinetd service would need to be restarted, for those changes to take. Actually, I was just playing with my linux box earlier and found that I can indeed ssh into the server. When I had the trouble, I had been running Windows 2000 from the same box. Some background... I have several small hdd´s that a friend gave me (4G) which I use to configure different systems on so that I can get familiar with them. I loaded win2k on such a drive and put it in a pull out bay and booted the system. I just used the same static ip that the regular system uses ´cause I didn´t want to add another host to my server. This was fine except that the machine name was different. I added that to the hosts file on the server. Anyway, I assume that my original problem must have been that I didn´t identify the Windows box the same as the linux box (ip, machine name, fqdn). As far as the telnet-server - done ;) I actually hadn´t realized that I had the server part installed -- doh! Be sure to urpme telnet-server sometime soon, though! ;) HTH! Yes! It does! Thanks -- Michael Holt Snohomish, WA (o_ [EMAIL PROTECTED](o_ (o_ //\ www.holt-tech.net(/)_ (/)_ V_/_www.mandrake.com ¨For we are God´s workmanship, created in Christ Jesus to do good works, which God prepared in advance for us to do.¨ Eph. 2:10 Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec level 4
Bryan Phinney mused: I would guess that something is either not configured correctly, you have installed some software that has changed the default settings, or you are hitting a different machine than you think you are hitting. I have tried this on my web server which is also set to msec level 4 and it does NOT work. Telnet connections are refused, just like SSH was initially until I opened that up using hosts.allow. It is possible that you have altered your hosts.deny file and the cron job that is supposed to change it back simply hasn't run yet, but it should get around to it. However, default at msec level 4 is to create a hosts.deny file that denies all. Until you explicitly allow connections in hosts.allow or remove hosts.deny, it should be refusing all connections. -- Bryan Phinney Software Test Engineer Hmm... I´m going to have to do some more playing around. I´ll let you know what I broke ;) -- Michael Holt Snohomish, WA (o_ [EMAIL PROTECTED](o_ (o_ //\ www.holt-tech.net(/)_ (/)_ V_/_www.mandrake.com ¨For we are God´s workmanship, created in Christ Jesus to do good works, which God prepared in advance for us to do.¨ Eph. 2:10 Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec and Directory permissions......
Ralph C wrote: Hi all, I have Bynari Insight Server installed and it installs everything inside /opt/is4/ directory as a chroot jail, where it runs it's own services like Postfix, Apache, Proftpd, etc... msec is changing the permissions. I need to make msec skip this directory and all sub dirs. How do I do this? Ralph Set your own permissions (customize what you want msec to do) on these directories. Try this site out for more info. http://www.mandrakesecure.net/en/docs/msec.php (it's kinda old but should serve your purpose) drjung -- J. Craig Woods UNIX Network/System Engineer http://www.trismegistus.net/resume.htm Let him that would move the world, first move himself. --Socrates Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec and Directory permissions......
Hi Jack, Thanks for the info. If I: edit /etc/security/msec/perm.local /opt/is4owner.group octalperms /opt/is4/* owner.group octalperms then (as per the second line) won't that change the owner.group octalperms ie. (775 for instance)for all of the sub dirs also? Remember that each of the dirs below (/opt/is4/) have different owner.group and permissions inside the chroot jail. I need to skip this dir not set/reset the owner.group and octalperms. So far the only way I have been able to avoid this is to stop the msec scripts from running. Any other ideas? Thanks Ralph Jack Coates wrote: On Wed, 2003-10-22 at 18:37, Ralph C wrote: Hi all, I have Bynari Insight Server installed and it installs everything inside /opt/is4/ directory as a chroot jail, where it runs it's own services like Postfix, Apache, Proftpd, etc... msec is changing the permissions. I need to make msec skip this directory and all sub dirs. How do I do this? Ralph edit /etc/security/msec/perm.local /opt/is4owner.group octalperms /opt/is4/* owner.group octalperms Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec and Directory permissions......
On Thu, 2003-10-23 at 07:33, Ralph Crpngeyer wrote: Hi Jack, Thanks for the info. If I: edit /etc/security/msec/perm.local /opt/is4 owner.group octalperms /opt/is4/*owner.group octalperms then (as per the second line) won't that change the owner.group octalperms ie. (775 for instance)for all of the sub dirs also? Remember that each of the dirs below (/opt/is4/) have different owner.group and permissions inside the chroot jail. I need to skip this dir not set/reset the owner.group and octalperms. uh, then why don't you add lines for each of those directories? IIRC there is a way to make msec ignore a directory, probably something like dots or asterisks, but... So far the only way I have been able to avoid this is to stop the msec scripts from running. Isn't the point of using a chroot to improve your security? If you're going to the trouble of using chroot, wouldn't you like to prevent ownership and permissions changes within the jails? Chroot jails are not playgrounds for the bad guys, they're subsystems that need the same if not higher security restrictions as the rest of the system. Any other ideas? I just looked through /usr/share/msec/perm.3, you can put current in the user.group area to preserve whatever's there. Dunno about perms. Thanks Ralph Jack Coates wrote: On Wed, 2003-10-22 at 18:37, Ralph C wrote: Hi all, I have Bynari Insight Server installed and it installs everything inside /opt/is4/ directory as a chroot jail, where it runs it's own services like Postfix, Apache, Proftpd, etc... msec is changing the permissions. I need to make msec skip this directory and all sub dirs. How do I do this? Ralph edit /etc/security/msec/perm.local /opt/is4 owner.group octalperms /opt/is4/* owner.group octalperms Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com __ Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com -- Jack Coates Monkeynoodle: A Scientific Venture... Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec and Directory permissions......
Jack, Your right. The user.group for the entire jail is root.root only the file permissions are different. Also looking at /usr/share/msec/perm.5 the directory /opt is not touched at all. I think that something else must have been happening. I wasn't the only one with root access to this system, till now. I just ran msec 5 and all is well. I think the answer to the question (How do I get msec to skip a dir?) is to make sure that it is not listed in the /usr/share/msec/perm.2/3/4/5 file. In other words, msec only changes owner.group perms for the dir's listed in the perm.2/3/4/5 file. Does that sound right? Thanks for your help. Ralph I think the answer to the question (How do I get msec to skip a dir?) is to make sure that it is not Jack Coates wrote: On Thu, 2003-10-23 at 07:33, Ralph Crpngeyer wrote: Hi Jack, Thanks for the info. If I: edit /etc/security/msec/perm.local /opt/is4owner.group octalperms /opt/is4/* owner.group octalperms then (as per the second line) won't that change the owner.group octalperms ie. (775 for instance)for all of the sub dirs also? Remember that each of the dirs below (/opt/is4/) have different owner.group and permissions inside the chroot jail. I need to skip this dir not set/reset the owner.group and octalperms. uh, then why don't you add lines for each of those directories? IIRC there is a way to make msec ignore a directory, probably something like dots or asterisks, but... So far the only way I have been able to avoid this is to stop the msec scripts from running. Isn't the point of using a chroot to improve your security? If you're going to the trouble of using chroot, wouldn't you like to prevent ownership and permissions changes within the jails? Chroot jails are not playgrounds for the bad guys, they're subsystems that need the same if not higher security restrictions as the rest of the system. Any other ideas? I just looked through /usr/share/msec/perm.3, you can put current in the user.group area to preserve whatever's there. Dunno about perms. Thanks Ralph Jack Coates wrote: On Wed, 2003-10-22 at 18:37, Ralph C wrote: Hi all, I have Bynari Insight Server installed and it installs everything inside /opt/is4/ directory as a chroot jail, where it runs it's own services like Postfix, Apache, Proftpd, etc... msec is changing the permissions. I need to make msec skip this directory and all sub dirs. How do I do this? Ralph edit /etc/security/msec/perm.local /opt/is4owner.group octalperms /opt/is4/* owner.group octalperms Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com __ Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec and Directory permissions......
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 October 23, 2003 09:36 am, Ralph Crpngeyer wrote: Jack, Your right. The user.group for the entire jail is root.root only the file permissions are different. Also looking at /usr/share/msec/perm.5 the directory /opt is not touched at all. I think that something else must have been happening. I wasn't the only one with root access to this system, till now. I just ran msec 5 and all is well. I think the answer to the question (How do I get msec to skip a dir?) is to make sure that it is not listed in the /usr/share/msec/perm.2/3/4/5 file. In other words, msec only changes owner.group perms for the dir's listed in the perm.2/3/4/5 file. Does that sound right? Thanks for your help. Ralph Ralph did you forget how to spell your own name, or have you taken to calling yourself Crpngyer for a reason? g Just curious 'cause I couldn't figure out what was bothering me about your posts. Regards; Charlie - -- Edmonton,AB,Canada User 244963 at http://counter.li.org Cooker on kernel 2.4.22-18mdk 10:39:39 up 17:40, 1 user, load average: 0.08, 0.22, 0.52 Really?? What a coincidence, I'm shallow too!! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/mAVAG11CaRuZZSIRAoBmAJ4sjt24IlFTG48gMLaCLcvE1HewaACgnTA8 CK0Gg0Inx0iHwyR3xKKN2xE= =j5y4 -END PGP SIGNATURE- Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec and Directory permissions......
On Thu, 2003-10-23 at 08:36, Ralph Crpngeyer wrote: Jack, Your right. The user.group for the entire jail is root.root only the file permissions are different. Also looking at /usr/share/msec/perm.5 the directory /opt is not touched at all. I think that something else must have been happening. I wasn't the only one with root access to this system, till now. I just ran msec 5 and all is well. I think the answer to the question (How do I get msec to skip a dir?) is to make sure that it is not listed in the /usr/share/msec/perm.2/3/4/5 file. In other words, msec only changes owner.group perms for the dir's listed in the perm.2/3/4/5 file. Does that sound right? or perm.local. Yeah, that sounds right. Thanks for your help. Ralph I think the answer to the question (How do I get msec to skip a dir?) is to make sure that it is not Jack Coates wrote: On Thu, 2003-10-23 at 07:33, Ralph Crpngeyer wrote: Hi Jack, Thanks for the info. If I: edit /etc/security/msec/perm.local /opt/is4owner.group octalperms /opt/is4/* owner.group octalperms then (as per the second line) won't that change the owner.group octalperms ie. (775 for instance)for all of the sub dirs also? Remember that each of the dirs below (/opt/is4/) have different owner.group and permissions inside the chroot jail. I need to skip this dir not set/reset the owner.group and octalperms. uh, then why don't you add lines for each of those directories? IIRC there is a way to make msec ignore a directory, probably something like dots or asterisks, but... So far the only way I have been able to avoid this is to stop the msec scripts from running. Isn't the point of using a chroot to improve your security? If you're going to the trouble of using chroot, wouldn't you like to prevent ownership and permissions changes within the jails? Chroot jails are not playgrounds for the bad guys, they're subsystems that need the same if not higher security restrictions as the rest of the system. Any other ideas? I just looked through /usr/share/msec/perm.3, you can put current in the user.group area to preserve whatever's there. Dunno about perms. Thanks Ralph Jack Coates wrote: On Wed, 2003-10-22 at 18:37, Ralph C wrote: Hi all, I have Bynari Insight Server installed and it installs everything inside /opt/is4/ directory as a chroot jail, where it runs it's own services like Postfix, Apache, Proftpd, etc... msec is changing the permissions. I need to make msec skip this directory and all sub dirs. How do I do this? Ralph edit /etc/security/msec/perm.local /opt/is4 owner.group octalperms /opt/is4/* owner.group octalperms Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com __ Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com __ Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com -- Jack Coates Monkeynoodle: A Scientific Venture... Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec and Directory permissions......
Thanks! I didn't even notice that I fat fingered my name. :-( Ralph Charlie M. wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 October 23, 2003 09:36 am, Ralph Crpngeyer wrote: Jack, Your right. The user.group for the entire jail is root.root only the file permissions are different. Also looking at /usr/share/msec/perm.5 the directory "/opt" is not touched at all. I think that something else must have been happening. I wasn't the only one with root access to this system, till now. I just ran "msec 5" and all is well. I think the answer to the question (How do I get msec to skip a dir?) is to make sure that it is not listed in the /usr/share/msec/perm.2/3/4/5 file. In other words, msec only changes "owner.group perms" for the dir's listed in the perm.2/3/4/5 file. Does that sound right? Thanks for your help. Ralph Ralph did you forget how to spell your own name, or have you taken to calling yourself "Crpngyer" for a reason? g Just curious 'cause I couldn't figure out what was bothering me about your posts. Regards; Charlie - -- Edmonton,AB,Canada User 244963 at http://counter.li.org Cooker on kernel 2.4.22-18mdk 10:39:39 up 17:40, 1 user, load average: 0.08, 0.22, 0.52 Really?? What a coincidence, I'm shallow too!! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/mAVAG11CaRuZZSIRAoBmAJ4sjt24IlFTG48gMLaCLcvE1HewaACgnTA8 CK0Gg0Inx0iHwyR3xKKN2xE= =j5y4 -END PGP SIGNATURE- Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec and Directory permissions......
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 October 23, 2003 11:46 am, Ralph Crongeyer wrote: Thanks! I didn't even notice that I fat fingered my name. :-( Ralph I think we all have those brain fart moments, don't we? My latest one was my son's e-mail address yesterday. I had him living in .cz instead of .ca. I did catch it before some SA like me pointed it out though. g You're welcome.(-: Charlie - -- Edmonton,AB,Canada User 244963 at http://counter.li.org Cooker on kernel 2.4.22-18mdk The best security update for Windows that I've found is the installer for Mandrake Linux. Especially the Use Entire Disk option. (-; -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/mBnAG11CaRuZZSIRAvLYAKCA4a4OQzPNuve3c9p2HT17AqOhawCbBrD8 nya2X6jpYzQGoQh+vw+MzXU= =PlYD -END PGP SIGNATURE- Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
[expert] msec and Directory permissions......
Hi all, I have Bynari Insight Server installed and it installs everything inside /opt/is4/ directory as a chroot jail, where it runs it's own services like Postfix, Apache, Proftpd, etc... msec is changing the permissions. I need to make msec skip this directory and all sub dirs. How do I do this? Ralph Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
[expert] msec and Directory permissions......
Hi all, I have Bynari Insight Server installed and it installs everything inside /opt/is4/ directory as a chroot jail, where it runs it's own services like Postfix, Apache, Proftpd, etc... msec is changing the permissions. I need to make msec skip this directory and all sub dirs. How do I do this? Ralph Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec and Directory permissions......
On Wed, 2003-10-22 at 18:37, Ralph C wrote: Hi all, I have Bynari Insight Server installed and it installs everything inside /opt/is4/ directory as a chroot jail, where it runs it's own services like Postfix, Apache, Proftpd, etc... msec is changing the permissions. I need to make msec skip this directory and all sub dirs. How do I do this? Ralph edit /etc/security/msec/perm.local /opt/is4owner.group octalperms /opt/is4/* owner.group octalperms -- Jack Coates Monkeynoodle: A Scientific Venture... Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec???
On Sunday 19 October 2003 11:25 pm, Michael Holt wrote: Ok, I´ve read all the posts I could find and it looks like no one has had any luck with msec? I´ve been doing fine forever at ´high´ security; now a friend from work is dogging me about making things more secure. Since he´s an m$ guy, I want to prove how much better *nix can do things and so I am off and ready to make that server of mine so secure that you can´t get ANYTHING done! Well, I´ve succeeded! I can´t get anything done! Ok, sorry ´bout that; now here´s my problem: When I go to msec level 4 - I can´t login to squirrelmail, use ssh, use ftp - I´m just about completely locked out. I´ve tried commenting out the line msec put in /etc/hosts.deny denying all, but it gets overwritten. I read a post about using chattr +i, but I´m using xfs so that´s no good. I tried adding ´authorize_services (all)´, but that didn´t help. I would really like to have secure level 4 or maybe even 5, but I need to be able to use my computer and I don´t know how to manually set the same environments without using msec. What can I do to fix this mess? I want the wheel group, etc. Msec level 4 denies everything by default. Therefore, you must explicitly allow the things that you want to allow in the hosts.allow file. This will override the hosts.deny file so that anything that is not allowed is denied. I had the same problem with my web server, once you understand that the default behavior is to deny, it makes perfect sense. -- Bryan Phinney Software Test Engineer Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec???
Bryan Phinney mused: Msec level 4 denies everything by default. Therefore, you must explicitly allow the things that you want to allow in the hosts.allow file. This will override the hosts.deny file so that anything that is not allowed is denied. I had the same problem with my web server, once you understand that the default behavior is to deny, it makes perfect sense. Yeah, that makes sense. I was reading different posts on HOW to allow things though, and trying to find which way would stick which was confusing. I put ´All: All´ in my allow file just so I can make it work and I found a sample allow file on the web that I´m going to play with when I get home from work today. Since you´re running a web server, would you mind posting a copy of yours? (/etc/hosts.allow file, that is). I´ve got kind of an ´all-in-one´ type of server - I don´t really have the resources to split things up. I´m running apache, webmail (postfix, squirrelmail, etc), samba, ftp, ssh, blah; just pretty much everything - on the same box. It would be nice to setup a firewall (other than port fowarding on my router), get msec all hardened up, and make everything all secure - but I think I have too many things going to do that. Anyway, all suggestions excepted :) Thanks -- Michael Holt Snohomish, WA (o_ [EMAIL PROTECTED](o_ (o_ //\ www.holt-tech.net(/)_ (/)_ V_/_www.mandrake.com There are 10 kinds of people in the world; those who understand binary, and those who don´t... Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec???
On Monday 20 October 2003 07:30 am, Michael Holt wrote: Yeah, that makes sense. I was reading different posts on HOW to allow things though, and trying to find which way would stick which was confusing. I put ´All: All´ in my allow file just so I can make it work and I found a sample allow file on the web that I´m going to play with when I get home from work today. Since you´re running a web server, would you mind posting a copy of yours? (/etc/hosts.allow file, that is). I wouldn't really mind but I don't think that it would do you any good. I do run a separate web server and since it is a public facing server, it would bear the brunt of most potential attacks, therefore, I purposefully keep it fairly locked down. I only allow SSH from within the local network, not from remote sites, and I purposefully limit the services run on it to known services. You have a more general purpose setup, so would have to open up more stuff. If you are not running a hardware router, I would highly suggest that you get one. Also, there are several security packages available that you should consider installing, portsentry, tripwire, logcheck, snort and perhaps even nessus to scan your own machine for possible exploits. If you have a hardware router, most of these should show up as negative unless you are actively running services. My current hosts.allow file might have something like the following: sshd: 192.168.0.? :ALLOW pureftpd: 192.168.0.? :ALLOW And that would be it. Other traffic is denied by default so any type of telnet or other connection would be dropped. Couple that with the firewall software and about the only traffic that can get through from outside is web traffic. I´ve got kind of an ´all-in-one´ type of server - I don´t really have the resources to split things up. I´m running apache, webmail (postfix, squirrelmail, etc), samba, ftp, ssh, blah; just pretty much everything - on the same box. It would be nice to setup a firewall (other than port fowarding on my router), get msec all hardened up, and make everything all secure - but I think I have too many things going to do that. Anyway, all suggestions excepted :) Unfortunately, you don't have much of a choice, with all of those services opened up, there is no substitute for a good firewall/hardware router and at minimum, several other security tools including, IMO, Snort (Intrusion detection), tripwire (checksum on files and changes), portsentry (detects and disables port scans), chkrootkit (checks for root kits), and logcheck (checks for modifications to the log file). Other suggestions, don't allow anonymous ftp access (that makes your server a target for script kiddies/warez kiddies), use RSA key encoding for SSH which provides an additional layer of security, Disallow Samba from external access with the firewall (I don't trust anything even if not MS but built to mimic MS stuff), and I would suggest tunneling the postfix and squirrelmail through SSH and disallowing those ports externally so that you get encryption and extra layers of security on the mail server. -- Bryan Phinney Software Test Engineer Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec???
Wow! Thanks for all the help Bryan! I´m going to go through the list and see what I can start implementing. Yeah, I do have a hardware router with port forwarding setup. I´m going to start playing with those other tools you mentioned. Thanks again -- Michael Holt Snohomish, WA (o_ [EMAIL PROTECTED](o_ (o_ //\ www.holt-tech.net(/)_ (/)_ V_/_www.mandrake.com There are 10 kinds of people in the world; those who understand binary, and those who don´t... Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
[expert] msec???
Ok, I´ve read all the posts I could find and it looks like no one has had any luck with msec? I´ve been doing fine forever at ´high´ security; now a friend from work is dogging me about making things more secure. Since he´s an m$ guy, I want to prove how much better *nix can do things and so I am off and ready to make that server of mine so secure that you can´t get ANYTHING done! Well, I´ve succeeded! I can´t get anything done! Ok, sorry ´bout that; now here´s my problem: When I go to msec level 4 - I can´t login to squirrelmail, use ssh, use ftp - I´m just about completely locked out. I´ve tried commenting out the line msec put in /etc/hosts.deny denying all, but it gets overwritten. I read a post about using chattr +i, but I´m using xfs so that´s no good. I tried adding ´authorize_services (all)´, but that didn´t help. I would really like to have secure level 4 or maybe even 5, but I need to be able to use my computer and I don´t know how to manually set the same environments without using msec. What can I do to fix this mess? I want the wheel group, etc. Thanks in advance! -- Michael Holt Snohomish, WA (o_ [EMAIL PROTECTED](o_ (o_ //\ www.holt-tech.net(/)_ (/)_ V_/_www.mandrake.com There are 10 kinds of people in the world; those who understand binary, and those who don´t... Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec???
On Sun, 2003-10-19 at 20:25, Michael Holt wrote: Ok, I´ve read all the posts I could find and it looks like no one has had any luck with msec? I´ve been doing fine forever at ´high´ security; now a friend from work is dogging me about making things more secure. Since he´s an m$ guy, I want to prove how much better *nix can do things and so I am off and ready to make that server of mine so secure that you can´t get ANYTHING done! Well, I´ve succeeded! I can´t get anything done! Ok, sorry ´bout that; now here´s my problem: When I go to msec level 4 - I can´t login to squirrelmail, use ssh, use ftp - I´m just about completely locked out. I´ve tried commenting out the line msec put in /etc/hosts.deny denying all, but it gets overwritten. I read a post about using chattr +i, but I´m using xfs so that´s no good. I tried adding ´authorize_services (all)´, but that didn´t help. I would really like to have secure level 4 or maybe even 5, but I need to be able to use my computer and I don´t know how to manually set the same environments without using msec. What can I do to fix this mess? I want the wheel group, etc. Thanks in advance! Start by read the /usr/share/msec/perm.* files, then apply changes to /etc/security/perm.local. Next, did you know that all the msec stuff is in script? Read it, quite enlightening. /usr/sbin/msec is the wrapper that figures out what to do, then calls python and bash scripts that live in /usr/share/msec. msec.py is the really powerful one. Look out for password aging, for instance :-) The bad news is that IIRC some of this stuff is dependent on kernel patches like GRSecurity, and so msec is toggling kernel flags that can only be touched during bootup. -- Jack Coates Monkeynoodle: A Scientific Venture... Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec???
Jack Coates mused: Start by read the /usr/share/msec/perm.* files, then apply changes to /etc/security/perm.local. Next, did you know that all the msec stuff is in script? Read it, quite enlightening. /usr/sbin/msec is the wrapper that figures out what to do, then calls python and bash scripts that live in /usr/share/msec. msec.py is the really powerful one. Look out for password aging, for instance :-) The bad news is that IIRC some of this stuff is dependent on kernel patches like GRSecurity, and so msec is toggling kernel flags that can only be touched during bootup. Cool, Thanks Jack -- Michael Holt Snohomish, WA (o_ [EMAIL PROTECTED](o_ (o_ //\ www.holt-tech.net(/)_ (/)_ V_/_www.mandrake.com There are 10 kinds of people in the world; those who understand binary, and those who don´t... Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
[expert] msec configuration problem
Hi, This question started actually in the newbie mailing list but it may be more appropriate for the expert list. I setup my machine with security level 4 but I am interested in relaxing some of the permission settings. I made changes to /etc/security/msec/perm.local and then executed msec. I found that msec does not make the requested changes unless I pass it the security level parameter as in msec 4 If I don't pass this parameter, the local changes are not executed. Even if I do pass this parameter, on the hour, cron executes /etc/cron.hourly/msec which again resets my local changes and reverts to the default. The reason for this is that in the following line in msec: /usr/share/msec/Perms.py $CHANGE $OPT /usr/share/msec/perm.$PERM_LEVEL $LOCAL $CHANGE is not set and therefore the local changes do not get saved. For now I hard coded in the msec script CHANGE=-c so that the changes will be saved. Is this a bug in msec or am I missing some setting which will force msec to use my local changes? Thanks, Avi Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec configuration problem
On Mon, 2003-09-01 at 20:11, Avi Schwartz wrote: Hi, This question started actually in the newbie mailing list but it may be more appropriate for the expert list. I setup my machine with security level 4 but I am interested in relaxing some of the permission settings. I made changes to /etc/security/msec/perm.local and then executed msec. I found that msec does not make the requested changes unless I pass it the security level parameter as in msec 4 If I don't pass this parameter, the local changes are not executed. Even if I do pass this parameter, on the hour, cron executes /etc/cron.hourly/msec which again resets my local changes and reverts to the default. The reason for this is that in the following line in msec: /usr/share/msec/Perms.py $CHANGE $OPT /usr/share/msec/perm.$PERM_LEVEL $LOCAL $CHANGE is not set and therefore the local changes do not get saved. For now I hard coded in the msec script CHANGE=-c so that the changes will be saved. Is this a bug in msec or am I missing some setting which will force msec to use my local changes? Thanks, Avi puzzling. Seems like a bug -- I can only assume that I've made my changes manually and then altered perm.local so they'll stick, otherwise I should have seen this too. -- Jack Coates Monkeynoodle: A Scientific Venture... Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec configuration problem
On Monday, Sep 1, 2003, at 22:55 America/Chicago, Jack Coates wrote: On Mon, 2003-09-01 at 20:11, Avi Schwartz wrote: Hi, This question started actually in the newbie mailing list but it may be more appropriate for the expert list. I setup my machine with security level 4 but I am interested in relaxing some of the permission settings. I made changes to /etc/security/msec/perm.local and then executed msec. I found that msec does not make the requested changes unless I pass it the security level parameter as in msec 4 If I don't pass this parameter, the local changes are not executed. Even if I do pass this parameter, on the hour, cron executes /etc/cron.hourly/msec which again resets my local changes and reverts to the default. The reason for this is that in the following line in msec: /usr/share/msec/Perms.py $CHANGE $OPT /usr/share/msec/perm.$PERM_LEVEL $LOCAL $CHANGE is not set and therefore the local changes do not get saved. For now I hard coded in the msec script CHANGE=-c so that the changes will be saved. Is this a bug in msec or am I missing some setting which will force msec to use my local changes? Thanks, Avi puzzling. Seems like a bug -- I can only assume that I've made my changes manually and then altered perm.local so they'll stick, otherwise I should have seen this too. Then there is something else going on since I also did the changes manually but the next time that cron ran msec is restored it to the default without taking into account my changes. If you look at your /etc/cron.hourly/msec is it a link to the msec executable? Avi Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec configuration problem
On Mon, 2003-09-01 at 21:06, Avi Schwartz wrote: ... puzzling. Seems like a bug -- I can only assume that I've made my changes manually and then altered perm.local so they'll stick, otherwise I should have seen this too. Then there is something else going on since I also did the changes manually but the next time that cron ran msec is restored it to the default without taking into account my changes. If you look at your /etc/cron.hourly/msec is it a link to the msec executable? Avi ... [EMAIL PROTECTED] jack]$ ll /etc/cron.hourly/msec lrwxr-xr-x1 root root 14 Sep 27 2002 /etc/cron.hourly/msec - /usr/sbin/msec check your log, sounds like msec isn't liking the perm.local file. -- Jack Coates Monkeynoodle: A Scientific Venture... Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
[expert] Msec automatic change :(
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all, I've just installed qmail on my mdk91. It was a success. However, a few minutes later i found this in /var/log/messages: Jul 11 13:01:01 mdk91 msec: changed mode of /usr/sbin/sendmail from 755 to 711 Jul 11 13:01:01 mdk91 msec: changed group of /usr/sbin/sendmail from qmail to mail Is it okay? How do I change the way msec operates? Thanks in advance, Fajar. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/DlOlUrYxG8KGMVERAgxgAJ9jar929Lg/OvqHChUSFIL1DSosjACeM3W2 gKEWRiewsF70FEmbiBfiObc= =cUaO -END PGP SIGNATURE- Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] Msec automatic change :(
On September 1993 plus 3599 days James Sparenberg wrote: On Thu, 2003-07-10 at 23:05, Fajar Priyanto wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all, I've just installed qmail on my mdk91. It was a success. However, a few minutes later i found this in /var/log/messages: Jul 11 13:01:01 mdk91 msec: changed mode of /usr/sbin/sendmail from 755 to 711 Jul 11 13:01:01 mdk91 msec: changed group of /usr/sbin/sendmail from qmail to mail Is it okay? How do I change the way msec operates? Thanks in advance, Fajar. rpm -e msec --nodeps *grin* (from one who has just about given up on msec *grin*) Bah, that's for chickens :P use drakperm to edit the perms for said files and you'll be problemless soon. Vox -- Think of the Linux community as a niche economy isolated by its beliefs. Kind of like the Amish, except that our religion requires us to use _higher_ technology than everyone else. -- Donald B. Marti Jr. pgp0.pgp Description: PGP signature
Re: [expert] Msec automatic change :(
On Thu, 2003-07-10 at 23:05, Fajar Priyanto wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all, I've just installed qmail on my mdk91. It was a success. However, a few minutes later i found this in /var/log/messages: Jul 11 13:01:01 mdk91 msec: changed mode of /usr/sbin/sendmail from 755 to 711 Jul 11 13:01:01 mdk91 msec: changed group of /usr/sbin/sendmail from qmail to mail Is it okay? How do I change the way msec operates? Thanks in advance, Fajar. rpm -e msec --nodeps *grin* (from one who has just about given up on msec *grin*) 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 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
[expert] msec madness continues
All; Ok, I'm ready to dump the whole thing in the bay. I have a server gone mad. After a power failure, the server came back in a very unstable state. So far, any efforts to fix it, seem to only make it worse. Every time I think I have it fixed, something else seems to go wrong. As it stands, most everything seems to be working, except mail. Im running imap on it. Any effort to check the mail, from either inside, or outside the lan results in the address of the host checking the mail getting blocked. The following lines get added to /var/log/messages Jan 12 16:29:36 ibu portsentry[2696]: attackalert: TCP SYN/Normal scan from host: chantika.keluarga.lan/192.168.100.3 to TCP port: 143 Jan 12 16:29:36 ibu portsentry[2696]: attackalert: Host 192.168.100.3 has been blocked via wrappers with string: ALL: 192.168.100.3 Can anyone shed some light on what's causing any effort to check the mail to be interpreted as an SYN attack? in short: HELP! THanks!! Ric Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec madness continues
On Sun, Jan 12, 2003 at 09:08:41PM -0500, Mark Weaver wrote: On Sunday 12 January 2003 08:42 pm, [EMAIL PROTECTED] scribbled incoherently: All; Ok, I'm ready to dump the whole thing in the bay. I have a server gone mad. After a power failure, the server came back in a very unstable state. So far, any efforts to fix it, seem to only make it worse. Every time I think I have it fixed, something else seems to go wrong. As it stands, most everything seems to be working, except mail. Im running imap on it. Any effort to check the mail, from either inside, or outside the lan results in the address of the host checking the mail getting blocked. The following lines get added to /var/log/messages Jan 12 16:29:36 ibu portsentry[2696]: attackalert: TCP SYN/Normal scan from host: chantika.keluarga.lan/192.168.100.3 to TCP port: 143 Jan 12 16:29:36 ibu portsentry[2696]: attackalert: Host 192.168.100.3 has been blocked via wrappers with string: ALL: 192.168.100.3 Can anyone shed some light on what's causing any effort to check the mail to be interpreted as an SYN attack? in short: HELP! THanks!! Ric Hi Ric, The very first thing I'd do is turn PS completely off. Better yet...just take the little bugger outa there cause in the long run that app is more trouble at times then it's worth. Once that thing isn't present to muck up the works you may have an easier time debugging the situation. I was running into that for a while some time back and got so sick of PS doing that very thing to me I just took it out. I've not been having any troubles like it since. And I'm still able to keep track of connections to the box just as well. It just gets done a little differently now. -- Mark Hi Mark; Thank you for the reply. Ok, I just shut off portsentry (service portsentry stop). Bastille-firewall is still running. (I'm open to suggestions on better firewalls... Been running Bastille for a while now. Never had any problems in the past. But this one is hair puller.. Ok, so after shutting down portsentry, I still can't get my e-Mail. I get a Failure to connect to server error at the client end. Nothing in the logs on the server. imap is listed in the Bastille config file. But the port seems blocked. If it's not bastille, what is it? Ric Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec madness continues
On Sun, Jan 12, 2003 at 09:36:39PM -0500, Mark Weaver wrote: On Sunday 12 January 2003 09:25 pm, [EMAIL PROTECTED] scribbled incoherently: Hi Ric, The very first thing I'd do is turn PS completely off. Better yet...just take the little bugger outa there cause in the long run that app is more trouble at times then it's worth. Once that thing isn't present to muck up the works you may have an easier time debugging the situation. I was running into that for a while some time back and got so sick of PS doing that very thing to me I just took it out. I've not been having any troubles like it since. And I'm still able to keep track of connections to the box just as well. It just gets done a little differently now. -- Mark Hi Mark; Thank you for the reply. Ok, I just shut off portsentry (service portsentry stop). Bastille-firewall is still running. (I'm open to suggestions on better firewalls... Been running Bastille for a while now. Never had any problems in the past. But this one is hair puller.. Ok, so after shutting down portsentry, I still can't get my e-Mail. I get a Failure to connect to server error at the client end. Nothing in the logs on the server. imap is listed in the Bastille config file. But the port seems blocked. If it's not bastille, what is it? Ric Ok...just to make sure, do a restart on both the Postfix service and the xinetd service to ensure they're running. This is usually the #1 cause of that particular error message when trying to connect to the imap service. It goes without saying that you've already got port 143 open for imap connections since you were connecting in that manner before. I too use Bastille, and haven't had any troubles with it. If you're still unable to connect just give a holler cause there's something tickling at the back of my neck for this, but I just can't put my finger on it. I'm sure though as we go through this it'll come to me. -- Mark GOT IT! (I hope!). Ok, I restarted both xinted, and postfix, and it works now! (whew). So now I need to check the runlevels to be sure xinetd company are in there. msec cleaned a bunch of stuff out for me... (grr...). In putting things back, I missed xinetd, hence the source of this round of troubles. But I think I'm about there now. (whew!). imap connections work from both inside, and outside, and the other services have come to life again. I was digging too deep into the problem. Xinetd was not running... Missed the obvious one.. Thank you! Thank you! Thank you! Ric Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec madness continues
On Sun, 2003-01-12 at 21:36, Mark Weaver wrote: On Sunday 12 January 2003 09:25 pm, [EMAIL PROTECTED] scribbled incoherently: Hi Ric, The very first thing I'd do is turn PS completely off. Better yet...just take the little bugger outa there cause in the long run that app is more trouble at times then it's worth. Once that thing isn't present to muck up the works you may have an easier time debugging the situation. I was running into that for a while some time back and got so sick of PS doing that very thing to me I just took it out. I've not been having any troubles like it since. And I'm still able to keep track of connections to the box just as well. It just gets done a little differently now. -- Mark Hi Mark; Thank you for the reply. Ok, I just shut off portsentry (service portsentry stop). Bastille-firewall is still running. (I'm open to suggestions on better firewalls... Been running Bastille for a while now. Never had any problems in the past. But this one is hair puller.. Ok, so after shutting down portsentry, I still can't get my e-Mail. I get a Failure to connect to server error at the client end. Nothing in the logs on the server. imap is listed in the Bastille config file. But the port seems blocked. If it's not bastille, what is it? Ric Ok...just to make sure, do a restart on both the Postfix service and the xinetd service to ensure they're running. This is usually the #1 cause of that particular error message when trying to connect to the imap service. It goes without saying that you've already got port 143 open for imap connections since you were connecting in that manner before. I too use Bastille, and haven't had any troubles with it. If you're still unable to connect just give a holler cause there's something tickling at the back of my neck for this, but I just can't put my finger on it. I'm sure though as we go through this it'll come to me. -- Mark Ok, I got it. The server even survived a reboot. I just had to piece the run levels back together. All seems well now. Thank you for the jump start. I'd been staring at it so long, I'd lost my perspective. ;) Ric Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec madness continues
On Sunday 12 January 2003 08:42 pm, [EMAIL PROTECTED] scribbled incoherently: All; Ok, I'm ready to dump the whole thing in the bay. I have a server gone mad. After a power failure, the server came back in a very unstable state. So far, any efforts to fix it, seem to only make it worse. Every time I think I have it fixed, something else seems to go wrong. As it stands, most everything seems to be working, except mail. Im running imap on it. Any effort to check the mail, from either inside, or outside the lan results in the address of the host checking the mail getting blocked. The following lines get added to /var/log/messages Jan 12 16:29:36 ibu portsentry[2696]: attackalert: TCP SYN/Normal scan from host: chantika.keluarga.lan/192.168.100.3 to TCP port: 143 Jan 12 16:29:36 ibu portsentry[2696]: attackalert: Host 192.168.100.3 has been blocked via wrappers with string: ALL: 192.168.100.3 Can anyone shed some light on what's causing any effort to check the mail to be interpreted as an SYN attack? in short: HELP! THanks!! Ric Hi Ric, The very first thing I'd do is turn PS completely off. Better yet...just take the little bugger outa there cause in the long run that app is more trouble at times then it's worth. Once that thing isn't present to muck up the works you may have an easier time debugging the situation. I was running into that for a while some time back and got so sick of PS doing that very thing to me I just took it out. I've not been having any troubles like it since. And I'm still able to keep track of connections to the box just as well. It just gets done a little differently now. -- Mark --- Paid for by Penguins against modern appliances(R) Linux User Since 1996 Powered by Mandrake Linux 8.2 9.0 Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec madness continues
On Sunday 12 January 2003 09:25 pm, [EMAIL PROTECTED] scribbled incoherently: Hi Ric, The very first thing I'd do is turn PS completely off. Better yet...just take the little bugger outa there cause in the long run that app is more trouble at times then it's worth. Once that thing isn't present to muck up the works you may have an easier time debugging the situation. I was running into that for a while some time back and got so sick of PS doing that very thing to me I just took it out. I've not been having any troubles like it since. And I'm still able to keep track of connections to the box just as well. It just gets done a little differently now. -- Mark Hi Mark; Thank you for the reply. Ok, I just shut off portsentry (service portsentry stop). Bastille-firewall is still running. (I'm open to suggestions on better firewalls... Been running Bastille for a while now. Never had any problems in the past. But this one is hair puller.. Ok, so after shutting down portsentry, I still can't get my e-Mail. I get a Failure to connect to server error at the client end. Nothing in the logs on the server. imap is listed in the Bastille config file. But the port seems blocked. If it's not bastille, what is it? Ric Ok...just to make sure, do a restart on both the Postfix service and the xinetd service to ensure they're running. This is usually the #1 cause of that particular error message when trying to connect to the imap service. It goes without saying that you've already got port 143 open for imap connections since you were connecting in that manner before. I too use Bastille, and haven't had any troubles with it. If you're still unable to connect just give a holler cause there's something tickling at the back of my neck for this, but I just can't put my finger on it. I'm sure though as we go through this it'll come to me. -- Mark --- Paid for by Penguins against modern appliances(R) Linux User Since 1996 Powered by Mandrake Linux 8.2 9.0 Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec madness continues
On Sunday 12 January 2003 10:12 pm, [EMAIL PROTECTED] scribbled incoherently: Ok...just to make sure, do a restart on both the Postfix service and the xinetd service to ensure they're running. This is usually the #1 cause of that particular error message when trying to connect to the imap service. It goes without saying that you've already got port 143 open for imap connections since you were connecting in that manner before. I too use Bastille, and haven't had any troubles with it. If you're still unable to connect just give a holler cause there's something tickling at the back of my neck for this, but I just can't put my finger on it. I'm sure though as we go through this it'll come to me. -- Mark GOT IT! (I hope!). Ok, I restarted both xinted, and postfix, and it works now! (whew). So now I need to check the runlevels to be sure xinetd company are in there. msec cleaned a bunch of stuff out for me... (grr...). In putting things back, I missed xinetd, hence the source of this round of troubles. But I think I'm about there now. (whew!). imap connections work from both inside, and outside, and the other services have come to life again. I was digging too deep into the problem. Xinetd was not running... Missed the obvious one.. Thank you! Thank you! Thank you! Ric Hi Ric, glad to hear all is well again. And you're quite welcome. it often takes two heads when one is currently buried up to it's armpits debugging things like that. Been there a few times myself. :) -- Mark --- Paid for by Penguins against modern appliances(R) Linux User Since 1996 Powered by Mandrake Linux 8.2 9.0 ICQ# 27816299 Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
[expert] msec security configuration
I was wondering how to customize my msec 3 security settings.The instructions in man mseclib are a little vague.Specifically I would like to enable PROMISC_CHECK=yes in level 3.Thanx. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Michael Shinobi a.k.a. 'alfalfa' Mandrake 8.2 Kernel-2.4.18-8.1mdk Linux user #298896 Fri Jan 3 13:42:49 EST 2003 1:42pm up 2 days, 15:51, 2 users, load average: 0.07, 0.04, 0.06 Homepage: http://micronuke.tripod.com/ Email: [EMAIL PROTECTED] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= If truth is beauty, how come no one has their hair done in the library? -- Lily Tomlin Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
[expert] MSEC is undoing my changes
I could use some help with msec. I found in the documentation how
you can use the /etc/security/msec/perm.local file to allow for
modifying permissions of a file. My problem is with modifying a file.
I've got a firewall running at security level 3. I want to modify some
files like /etc/syslogd.conf and /etc/issue{.net}; However, msec keeps
undoing my changes.
Any help would be greately appreciated.
Thanks,
Cory
Want to buy your Pack or Services from MandrakeSoft?
Go to http://www.mandrakestore.com
Re: [expert] MSEC is undoing my changes
On Sun, 2002-11-03 at 06:11, . wrote:
I could use some help with msec. I found in the documentation how
you can use the /etc/security/msec/perm.local file to allow for
modifying permissions of a file. My problem is with modifying a file.
I've got a firewall running at security level 3. I want to modify some
files like /etc/syslogd.conf and /etc/issue{.net}; However, msec keeps
undoing my changes.
Any help would be greately appreciated.
Thanks,
Cory
edit /usr/share/msec/perm.3 and make the changes you want.
--
Jack Coates
Monkeynoodle: A Scientific Venture...
Want to buy your Pack or Services from MandrakeSoft?
Go to http://www.mandrakestore.com
Re: [expert] MSEC is undoing my changes
On Sunday 03 November 2002 11:54 am, Jack Coates wrote:
On Sun, 2002-11-03 at 06:11, . wrote:
I could use some help with msec. I found in the documentation how
you can use the /etc/security/msec/perm.local file to allow for
modifying permissions of a file. My problem is with modifying a file.
I've got a firewall running at security level 3. I want to modify some
files like /etc/syslogd.conf and /etc/issue{.net}; However, msec keeps
undoing my changes.
Any help would be greately appreciated.
Thanks,
Cory
edit /usr/share/msec/perm.3 and make the changes you want.
Or make your own rules in the Mandrake Control Center, which are supposed to
overide the defaults for each level. I think it is Security -- Security
Permissions applet. Choose editable from the drop down, and enter your
rules.
--
/g
___
[EMAIL PROTECTED]
Want to buy your Pack or Services from MandrakeSoft?
Go to http://www.mandrakestore.com
Re: [expert] MSEC is undoing my changes
Gregory K. Meyer wrote:
On Sunday 03 November 2002 11:54 am, Jack Coates wrote:
On Sun, 2002-11-03 at 06:11, . wrote:
I could use some help with msec. I found in the documentation how
you can use the /etc/security/msec/perm.local file to allow for
modifying permissions of a file. My problem is with modifying a file.
I've got a firewall running at security level 3. I want to modify some
files like /etc/syslogd.conf and /etc/issue{.net}; However, msec keeps
"undoing" my changes.
Any help would be greately appreciated.
Thanks,
Cory
edit /usr/share/msec/perm.3 and make the changes you want.
Or make your own rules in the Mandrake Control Center, which are supposed to
overide the defaults for each level. I think it is Security -- Security
Permissions applet. Choose editable from the drop down, and enter your
rules.
Right, and that makes a /etc/security/perm.local file, right? This is
a firewall, so it has no gui, but I created that file manually. I put the
/etc/syslog.conf file in the perm.local file with it's original owner, group,
and permissions. I didn't want to change any of that, I just wanted msec
to quit overlaying my changes within the file. If I modify the entry in
perm.local to change ownership or permissions, will that get msec to leave
it alone? Otherwise, I don't see how the perm.local file helps me in this
situation.
Thanks,
Cory
Want to buy your Pack or Services from MandrakeSoft?
Go to http://www.mandrakestore.com
Re: [expert] MSEC is undoing my changes
Never mind ... I have it working on one of my machines, so now I just
have to figure out what I did so it will work on the other one. I'll post
the answer when I have it, in case anyone else has the same problems.
BTW ... here's the changes I made to /etc/init.d/sendmail. Running "sendmail
-L sm-msp-que -Ac" for the client ueue puts .pid file in /var/spool/clientmqueue
instead of /var/run. The original script touched a /var/run/sm-client.pid
and chowned it to smmsp (why not mail?), but since it didn't contain the PID
#, the stop script failed. I commented out those two lines and added a mv
and chmod line of my own, after the daemon function call. Here:
if ! test -f /var/run/sm-client.pid ; then
gprintf "Starting sm-client: "
# touch /var/run/sm-client.pid # -- HERE
# chown smmsp:smmsp /var/run/sm-client.pid # -- HERE
daemon --check sm-client /usr/sbin/sendmail -L sm-msp-queue -Ac \
$([ -n "$QUEUE" ] echo -q$QUEUE)
RETVAL=$?
sleep 5
mv /var/spool/clientmqueue/sm-client.pid /var/run # -- HERE
chown mail:mail /var/run/sm-client.pid # -- HERE
echo
I think it still has a problem on systems running the client only daemon
(DAEMON=no in /etc/sysconfig/sendmail), so I still have to work on that. Oh,
and I made another change. The /etc/init.d/sendmail script wasn't checking
the DAEMON variable, so it was starting the listening process no matter what.
So I added a "[ $DAEMON = "yes" ] " in a couple of spots:
[ $DAEMON = "yes" ] gprintf "Starting %s: " "$prog"
/usr/bin/newaliases /dev/null 21
if test -x /usr/bin/make -a -f /etc/mail/Makefile ; then
make -C /etc/mail -s
else
for i in virtusertable access domaintable mailertable ; do
if [ -f /etc/mail/$i ] ; then
makemap hash /etc/mail/$i /etc/mail/$i
fi
done
fi
[ $DAEMON = "yes" ] daemon /usr/sbin/sendmail -bd \
$([ -n "$QUEUE" ] echo -q$QUEUE)
That's it.
Cory wrote:
I could
use some help with msec. I found in the documentation how you can use the
/etc/security/msec/perm.local file to allow for modifying permissions of
a file. My problem is with modifying a file. I've got a firewall running
at security level 3. I want to modify some files like /etc/syslogd.conf
and /etc/issue{.net}; However, msec keeps "undoing" my changes.
Any help would be greately appreciated.
Thanks,
Cory
Want to buy your Pack or Services from MandrakeSoft?
Go to http://www.mandrakestore.com
Re: [expert] MSEC is undoing my changes
On Sun, 2002-11-03 at 09:52, Gregory K. Meyer wrote:
On Sunday 03 November 2002 11:54 am, Jack Coates wrote:
On Sun, 2002-11-03 at 06:11, . wrote:
I could use some help with msec. I found in the documentation how
you can use the /etc/security/msec/perm.local file to allow for
modifying permissions of a file. My problem is with modifying a file.
I've got a firewall running at security level 3. I want to modify some
files like /etc/syslogd.conf and /etc/issue{.net}; However, msec keeps
undoing my changes.
Any help would be greately appreciated.
Thanks,
Cory
edit /usr/share/msec/perm.3 and make the changes you want.
Or make your own rules in the Mandrake Control Center, which are supposed to
overide the defaults for each level. I think it is Security -- Security
Permissions applet. Choose editable from the drop down, and enter your
rules.
--
/g
___
Is that working now? perm.local files never worked for me in 8.2,
haven't tried on 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 is undoing my changes
On Sunday 03 November 2002 01:54 pm, . wrote: Right, and that makes a /etc/security/perm.local file, right? This /etc/security/msec/local is a firewall, so it has no gui, but I created that file manually. I put the /etc/syslog.conf file in the perm.local file with it's original owner, group, and permissions. I didn't want to change any of that, I just wanted msec to quit overlaying my changes within the file. If I modify the entry in perm.local to change ownership or permissions, will that get msec to leave it alone? Otherwise, I don't see how the perm.local file helps me in this situation. perm.local is supposed to override any setting in perm.whatever. -- /g ___ [EMAIL PROTECTED] Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
[expert] msec doing unsecure things?
Hi, just came back from a trip to the Mandrake newsgroup and I'm still in terror! I read a thread about the default behaviour of msec concerning the permissions of home directories. So I made a fresh install of MDK 8.2 from the boxed version with sec level 'Standard', created 2 dummy users (joe anne) and lokked at he result: [anne@molch home]$ ls -l insgesamt 2 drwxw-xw-x3 joe joe184 Jun 10 13:07 joe/ drwxw-xw-x3 anne anne 184 Jun 10 13:07 joeanne/ [anne@molch home]$ cd joe [anne@molch joe]$ ls -a ./ ../ .bash_logout .bash_profile .bashrc .mailcap tmp/ [anne@molch joe]$ less .bashrc # .bashrc # User specific aliases and functions # Source global definitions if [ -f /etc/bashrc ]; then . /etc/bashrc fi .bashrc lines 1-8/8 (END) Anne can read all of Joe's files. Now I did 'msec 3' as root. The result: [anne@molch home]$ ls -l insgesamt 2 drwx--x--x3 joe joe184 Jun 10 13:07 joe/ drwx--x--x3 anne anne 184 Jun 10 13:07 anne/ [anne@molch home]$ cd joe [anne@molch joe]$ ls -a ls: .: Permission denied Here you go! Isn't that the state of permissions which should have been there from the start? My experiment just tells the same as what I read in the newsgroup: Although sec level 'Standard' is given during installation, after the install all users can read all other user's files. Only by manually punching in the msec command I get the 'normal' secure status. Now who of the not-so-worn-out Linux users knows the msec command? Who of the newbies even knows that he may have to do something? The unsuspicious newbie does an installation of a presumably more secure system than he is used to in Win9x/ME but what does he really get??? wobo -- Registered Linux User 228909 Powered By Mandrake Linux sum(8.1+0.1) - Microsoft, Windows, Bugs, Lacking Features, IRQ Conflicts, System Crashes, Non-Functional Multitasking and The Blue Screen of Death (BSOD) are registered trademarks of Microsoft Corp., Redmond, Washington, USA. Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec doing unsecure things?
An exceptional analysis of the situation. Security being a tool which is generally overlooked. Having gotten used to the lax security, I was shocked to find that the items I've gotten used to were now eliminated for Security reasons. Certainly this is a step forward. Wolfgang Bornath wrote: Hi, just came back from a trip to the Mandrake newsgroup and I'm still in terror! I read a thread about the default behaviour of msec concerning the permissions of home directories. So I made a fresh install of MDK 8.2 from the boxed version with sec level 'Standard', created 2 dummy users (joe anne) and lokked at he result: [anne@molch home]$ ls -l insgesamt 2 drwxw-xw-x3 joe joe184 Jun 10 13:07 joe/ drwxw-xw-x3 anne anne 184 Jun 10 13:07 joeanne/ [anne@molch home]$ cd joe [anne@molch joe]$ ls -a ./ ../ .bash_logout .bash_profile .bashrc .mailcap tmp/ [anne@molch joe]$ less .bashrc # .bashrc # User specific aliases and functions # Source global definitions if [ -f /etc/bashrc ]; then . /etc/bashrc fi .bashrc lines 1-8/8 (END) Anne can read all of Joe's files. Now I did 'msec 3' as root. The result: [anne@molch home]$ ls -l insgesamt 2 drwx--x--x3 joe joe184 Jun 10 13:07 joe/ drwx--x--x3 anne anne 184 Jun 10 13:07 anne/ [anne@molch home]$ cd joe [anne@molch joe]$ ls -a ls: .: Permission denied Here you go! Isn't that the state of permissions which should have been there from the start? My experiment just tells the same as what I read in the newsgroup: Although sec level 'Standard' is given during installation, after the install all users can read all other user's files. Only by manually punching in the msec command I get the 'normal' secure status. Now who of the not-so-worn-out Linux users knows the msec command? Who of the newbies even knows that he may have to do something? The unsuspicious newbie does an installation of a presumably more secure system than he is used to in Win9x/ME but what does he really get??? wobo -- Registered Linux User 228909 Powered By Mandrake Linux sum(8.1+0.1) - Microsoft, Windows, Bugs, Lacking Features, IRQ Conflicts, System Crashes, Non-Functional Multitasking and The Blue Screen of Death (BSOD) are registered trademarks of Microsoft Corp., Redmond, Washington, USA. Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com -- Albert E. Whale - CISSP http://www.abs-comptech.com -- ABS Computer Technology, Inc. - ESM, Computer Networking Specialists Sr. Security, Network, and Systems Consultant Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec doing unsecure things?
On Monday 10 June 2002 08:04 am, you wrote: Hi, just came back from a trip to the Mandrake newsgroup and I'm still in terror! I read a thread about the default behaviour of msec concerning the permissions of home directories. So I made a fresh install of MDK 8.2 from the boxed version with sec level 'Standard', created 2 dummy users (joe anne) and lokked at he result: [anne@molch home]$ ls -l insgesamt 2 drwxw-xw-x3 joe joe184 Jun 10 13:07 joe/ drwxw-xw-x3 anne anne 184 Jun 10 13:07 joeanne/ [anne@molch home]$ cd joe [anne@molch joe]$ ls -a ./ ../ .bash_logout .bash_profile .bashrc .mailcap tmp/ [anne@molch joe]$ less .bashrc # .bashrc # User specific aliases and functions # Source global definitions if [ -f /etc/bashrc ]; then . /etc/bashrc fi .bashrc lines 1-8/8 (END) Anne can read all of Joe's files. Now I did 'msec 3' as root. The result: [anne@molch home]$ ls -l insgesamt 2 drwx--x--x3 joe joe184 Jun 10 13:07 joe/ drwx--x--x3 anne anne 184 Jun 10 13:07 anne/ [anne@molch home]$ cd joe [anne@molch joe]$ ls -a ls: .: Permission denied Here you go! Isn't that the state of permissions which should have been there from the start? My experiment just tells the same as what I read in the newsgroup: Although sec level 'Standard' is given during installation, after the install all users can read all other user's files. Only by manually punching in the msec command I get the 'normal' secure status. Now who of the not-so-worn-out Linux users knows the msec command? Who of the newbies even knows that he may have to do something? The unsuspicious newbie does an installation of a presumably more secure system than he is used to in Win9x/ME but what does he really get??? wobo his security is better than m$winblows even at level 1 msec, since he still has to know the root password to install programs or write to system files. yes or no? Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec doing unsecure things?
On Mon, 10 Jun 2002, Wolfgang Bornath wrote: Hi, just came back from a trip to the Mandrake newsgroup and I'm still in terror! I read a thread about the default behaviour of msec concerning the permissions of home directories. So I made a fresh install of MDK 8.2 from the boxed version with sec level 'Standard', created 2 dummy users (joe anne) and lokked at he result: [small snip] Here you go! Isn't that the state of permissions which should have been there from the start? My experiment just tells the same as what I read in the newsgroup: Although sec level 'Standard' is given during installation, after the install all users can read all other user's files. Only by manually punching in the msec command I get the 'normal' secure status. Now who of the not-so-worn-out Linux users knows the msec command? Who of the newbies even knows that he may have to do something? The unsuspicious newbie does an installation of a presumably more secure system than he is used to in Win9x/ME but what does he really get??? wobo wobo, dude! thanks for the headsup. this is one not-so-worn-out Linux user that wasn't aware of msec apart from hearing it mentioned now and then on the lists, but one that has taken your advice and taken care of bidness. perms on my server and workstations are now as they should be. thanks! ;) -- Mark a.k.a. daRcmaTTeR -- If your wife told you NOT to do it there's probably a real good reason! - REGISTERED LINUX USER #186492 Penguinized since 1997 Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec doing unsecure things?
On Mon, Jun 10, 2002 at 15:21 -0400, et wrote: On Monday 10 June 2002 08:04 am, you wrote: [snip] Here you go! Isn't that the state of permissions which should have been there from the start? My experiment just tells the same as what I read in the newsgroup: Although sec level 'Standard' is given during installation, after the install all users can read all other user's files. Only by manually punching in the msec command I get the 'normal' secure status. Now who of the not-so-worn-out Linux users knows the msec command? Who of the newbies even knows that he may have to do something? The unsuspicious newbie does an installation of a presumably more secure system than he is used to in Win9x/ME but what does he really get??? wobo his security is better than m$winblows even at level 1 msec, since he still has to know the root password to install programs or write to system files. yes or no? That is not the point here. Here we talk about a situation that the user is told he has a good security system but in reality all other users of his computer can read his private files. In Windows I *know* about weak security and I act accordingly. In Linux everybody tells me about how secure Linux is. wobo -- Registered Linux User 228909 Powered By Mandrake Linux sum(8.1+0.1) - Microsoft, Windows, Bugs, Lacking Features, IRQ Conflicts, System Crashes, Non-Functional Multitasking and The Blue Screen of Death (BSOD) are registered trademarks of Microsoft Corp., Redmond, Washington, USA. Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec doing unsecure things?
If there is no origianl message included in theis rely, i apologize...reply is doing funny things today. Anyway, this is a reply to etharp's last post: Yes, the default mandrake security settings are far more secure than windoze, or most other OS's. Not only can joe and joeanne not install systemwide programs without root authority, being able to read eachother's files does not give them permission to modify each other's files. in windoze, you can usually modify any file you can see, unless the owner has specifically locked it. So the only security issue here relates to personal privacy and possibly sensitive information, not to system security. But then if you're worried about national security or industrial espionage--or simply making sure your coworkers don't find out that your made from scratch cookies reall come out of a Betty Crocker box--you should probably make yourself familiar with chmod and some encryption programs, anyway. Furthermore, a+rx acces has been the standard on most Unices I've dealt with . . . that, or giving all users a common GID. Why? I don't know, although I suspect it may be a holdover days of slower networking and pre-X network terminals. It's very easy to share files when you can just tell a person where a file is, and they can go copy it for themself. Patiularly when pre-mime e-mail and other transport protocals required you to tar. shar, and/or uuencode binary files to send them to other users. In fact, my first Unix reference for the Umich system when I was an undergrad recommended using cp or ln (preferrably ln) to grap programs you wanted/needed from friends' directories instead of bugging the sysadmin to install software for you. And another thought: if you want to share a file with a group, the other members of the group (potentially anyone on the system) all need access to the entire path, unless the admin does something like set up hardlinks from ~/share to /usr/share/[username]_public, or something. Anyway, this very long message was vasically to say that, while there are many times you may want stronger security for one reason or another, the default msec values look pretty good to me. Hope this helps, --jay _ Save rainforest! Redjellyfish Long Distance works just like any other long distance provider and is very competitively priced. In addition, youll save rainforest every time you make a long distance call! To learn more visit: http://www.redjellyfish.com/longdistance Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec doing unsecure things?
On Monday 10 June 2002 04:56 pm, you wrote: On Mon, Jun 10, 2002 at 15:21 -0400, et wrote: On Monday 10 June 2002 08:04 am, you wrote: [snip] Here you go! Isn't that the state of permissions which should have been there from the start? My experiment just tells the same as what I read in the newsgroup: Although sec level 'Standard' is given during installation, after the install all users can read all other user's files. Only by manually punching in the msec command I get the 'normal' secure status. Now who of the not-so-worn-out Linux users knows the msec command? Who of the newbies even knows that he may have to do something? The unsuspicious newbie does an installation of a presumably more secure system than he is used to in Win9x/ME but what does he really get??? wobo his security is better than m$winblows even at level 1 msec, since he still has to know the root password to install programs or write to system files. yes or no? That is not the point here. Here we talk about a situation that the user is told he has a good security system but in reality all other users of his computer can read his private files. In Windows I *know* about weak security and I act accordingly. In Linux everybody tells me about how secure Linux is. wobo gee... everyone tells me about the choice linux gives, if you want seure you can go up to paranoid, but most newbies would like to be able to choose. Of course if the discriptions of the difference in security levels is not very clear, maybe that is what the problem is? Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
[expert] msec, kernel panic and zip drive
Summary: When msec is run (at 4:03 am) it seems to trigger a kernel panic. I have also got the same kernel panic when shutting down, right after Alsa has been stopped. In either case, when this happens, I have to resort to the SysRq sequence. This seems to be related to the zip drive: # uname -a Linux xxx.new.rr.com 2.4.18-6mdk #1 Thu Mar 28 22:32:10 EST 2002 i686 unknown I've looked for this on Cooker and have seen some vague talk about ide-cd possibly being at fault, but nothing about how to fix this in 8.2. Does anybody here know what to do? Attached: /etc/fstab and a part of /etc/lilo.conf. Below: Output from /var/log/messages. Thanks, Narfi. CROND[12083]: (root) CMD (nice -n 19 run-parts /etc/cron.daily) anacron[12086]: Updated timestamp for job `cron.daily' to 2002-05-23 kernel: Device not ready. Make sure there is a disc in the drive. kernel: sda : READ CAPACITY failed. kernel: sda : status = 0, message = 00, host = 0, driver = 28 kernel: Current sd00:00: sense key Not Ready kernel: Additional sense indicates Medium not present kernel: sda : block size assumed to be 512 bytes, disk size 1GB. kernel: /dev/scsi/host0/bus0/target0/lun0: I/O error: dev 08:00, sector 0 kernel: I/O error: dev 08:00, sector 2 kernel: I/O error: dev 08:00, sector 0 kernel: Unable to handle kernel paging request at virtual address 204f2f8d kernel: printing eip: kernel: c0161873 kernel: *pde = kernel: Oops: kernel: CPU:0 kernel: EIP:1010:[devfs_read_super+51/208]Tainted: P kernel: EIP:1010:[c0161873]Tainted: P kernel: EFLAGS: 00010202 kernel: eax: cd53ccc0 ebx: 204f2f49 ecx: edx: cd53ccc0 kernel: esi: cdf38380 edi: df7bdbc0 ebp: c9c504a0 esp: ddbfbf28 kernel: ds: 1018 es: 1018 ss: 1018 kernel: Process msec_find (pid: 12182, stackpage=ddbfb000) kernel: Stack: cdf38380 c0161d06 df7bdbc0 c02676a0 cdf38380 cdf38400 cdf383ec kernel:c9c504a0 c0142780 c9c504a0 ddbfbfa0 c0142c80 c9c504a0 fff7 000d kernel:bfffecd8 c0142e2f c9c504a0 c0142c80 ddbfbfa0 cdf392e0 c01349e7 cdf392e0 kernel: Call Trace: [devfsd_ioctl+54/304] [do_poll+96/240] [fifo_open+160/601] [fifo_open+591/601] [fifo_open+160/601] kernel: Call Trace: [c0161d06] [c0142780] [c0142c80] [c0142e2f] [c0142c80] kernel:[do_readv_writev+663/704] [do_simd_coprocessor_error+35/128] kernel:[c01349e7] [c0107fc3] kernel: kernel: Code: 66 8b 43 44 25 00 f0 00 00 66 3d 00 60 75 0d f6 43 10 04 74 /dev/hde1 / ext2 defaults 1 1 none /dev/pts devpts mode=0620 0 0 none /dev/shm tmpfs defaults 0 0 /dev/hde7 /home ext2 defaults 1 2 /dev/sdb1 /mnt/camera auto noauto,ro /mnt/cdrom /mnt/cdrom supermount dev=/dev/scd0,fs=iso9660,ro,--,iocharset=iso8859-1 0 0 /mnt/cdrom2 /mnt/cdrom2 supermount dev=/dev/hdg,fs=iso9660,ro,--,iocharset=iso8859-1 0 0 /mnt/floppy /mnt/floppy supermount dev=/dev/fd0,fs=vfat,--,iocharset=iso8859-1,sync,codepage=850 0 0 /dev/hda1 /mnt/win_c vfat iocharset=iso8859-1,codepage=850,umask=002,gid=100,setgid=100 0 0 /dev/hda5 /mnt/win_d vfat iocharset=iso8859-1,codepage=850,umask=002,gid=100,setgid=100 0 0 /mnt/zip /mnt/zip supermount dev=/dev/sda4,fs=vfat,--,iocharset=iso8859-1,sync,codepage=850 0 0 /dev/hde9 /opt ext3 defaults 1 2 none /proc proc defaults 0 0 /dev/hde8 /projects ext3 defaults 1 2 /dev/hde6 /usr ext2 defaults 1 2 /dev/hde10 /var ext2 defaults 1 2 /dev/hde5 swap swap defaults 0 0 # added by NeTraverse - DO NOT REMOVE THIS LINE, it's used for uninstall default=win4lin # end added by NeTraverse - DO NOT REMOVE THIS LINE, it's used for uninstall boot=/dev/hde map=/boot/map install=/boot/boot.b vga=normal keytable=/boot/us.klt lba32 prompt nowarn timeout=100 message=/boot/message menu-scheme=wb:bw:wb:bw ignore-table disk=/dev/hda bios=0x81 disk=/dev/hde bios=0x80 image=/boot/vmlinuz label=linux root=/dev/hde1 initrd=/boot/initrd.img append=nobiospnp devfs=mount hdc=ide-scsi hdb=ide-scsi vga=788 read-only Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
[expert] msec changes Mailman perms
I'm using LM 8.2 (new install), and running several mailing list. At msec 3 4 I am continually having to reset the /home/mailman perms back to 02775. Does anyone have a suggestion on how I can stop the madness? -- Albert E. Whale - CISSP http://www.abs-comptech.com -- ABS Computer Technology, Inc. - ESM, Computer Networking Specialists Sr. Security, Network, and Systems Consultant Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec changes Mailman perms
I'm not sure of the exact file, since I'm not running a mailing list, and don't have a /home/mailman. However, if I were you, I'd look at the msec config files in /usr/share/msec Just a thought. I may be wrong. Ric On Sun, 2002-06-02 at 08:49, Albert E. Whale wrote: I'm using LM 8.2 (new install), and running several mailing list. At msec 3 4 I am continually having to reset the /home/mailman perms back to 02775. Does anyone have a suggestion on how I can stop the madness? -- Albert E. Whale - CISSP http://www.abs-comptech.com -- ABS Computer Technology, Inc. - ESM, Computer Networking Specialists Sr. Security, Network, and Systems Consultant Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec changes Mailman perms
At 10:45 AM 6/2/02, you wrote: I'm not sure of the exact file, since I'm not running a mailing list, and don't have a /home/mailman. However, if I were you, I'd look at the msec config files in /usr/share/msec Just a thought. I may be wrong. Ric On Sun, 2002-06-02 at 08:49, Albert E. Whale wrote: I'm using LM 8.2 (new install), and running several mailing list. At msec 3 4 I am continually having to reset the /home/mailman perms back to 02775. Does anyone have a suggestion on how I can stop the madness? Albert, There have been several threads on this list about msec permissions. In particular there's an article about msec on the mandrake security. There's also a file, /etc/security/msec/level.local for overriding the behavior of the msec program. Between the two of these, you should be able to learn/do what you want. David Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec changes Mailman perms
On Sun, 02 Jun 2002 11:11:26 -0400 David Relson [EMAIL PROTECTED] wrote: At 10:45 AM 6/2/02, you wrote: I'm not sure of the exact file, since I'm not running a mailing list, and don't have a /home/mailman. However, if I were you, I'd look at the msec config files in /usr/share/msec Just a thought. I may be wrong. Ric On Sun, 2002-06-02 at 08:49, Albert E. Whale wrote: I'm using LM 8.2 (new install), and running several mailing list. At msec 3 4 I am continually having to reset the /home/mailman perms back to 02775. Does anyone have a suggestion on how I can stop the madness? Albert, There have been several threads on this list about msec permissions. In particular there's an article about msec on the mandrake security. There's also a file, /etc/security/msec/level.local for overriding the behavior of the msec program. Between the two of these, you should be able to learn/do what you want. David Msec doesn't seem to always honor that level.local file which makes it especially difficult to set the security settings you desire. -- Brian - [EMAIL PROTECTED] My Home Page: http://www.brimac.com/~brianmac Fine Photos: http://www.brimacphotography.com Art for Sale: http://www.artbrowser.com Classified Advertising: http://www.sellit2000.com Information: http://www.somebodyyoucancall.com Hang On Sloopy is the official rock song of Ohio. Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec changes Mailman perms
Brian wrote: Msec doesn't seem to always honor that level.local file which makes it especially difficult to set the security settings you desire. -- It works just fine on my system (LMDK8.2). Take a look at the Mandrake page for instructions. You might want to look at the creation of a file named perm.local. I don't even use a file named level.local, and I can control all perms on *every* file in my system. I works perfectly for the kind of thing the original poster asked about fixing. drjung -- J. Craig Woods UNIX/NT Network/System Administration http://www.trismegistus.net/resume.html Character is built upon the debris of despair --Emerson Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec changes Mailman perms
On Sun, 02 Jun 2002 10:51:33 -0500 J. Craig Woods [EMAIL PROTECTED] wrote: Brian wrote: Msec doesn't seem to always honor that level.local file which makes it especially difficult to set the security settings you desire. -- It works just fine on my system (LMDK8.2). Take a look at the Mandrake page for instructions. You might want to look at the creation of a file named perm.local. I don't even use a file named level.local, and I can control all perms on *every* file in my system. I works perfectly for the kind of thing the original poster asked about fixing. drjung -- My problem was with things like auto logout refused to be disabled. Booted up with my preferred settings but after an hour or so, they changed back to default settings regardles of what I set in level.local. -- Brian - [EMAIL PROTECTED] My Home Page: http://www.brimac.com/~brianmac Fine Photos: http://www.brimacphotography.com Art for Sale: http://www.artbrowser.com Classified Advertising: http://www.sellit2000.com Information: http://www.somebodyyoucancall.com A cannibal only opens his mouth to change your feet. Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
[expert] msec changes Mailman perms
I'm using LM 8.2 (new install), and running several mailing list. I have grown to like MailMan, a GNU tool. At msec 3 4 I am continually having to reset the /home/mailman perms back to 02775. Does anyone have a suggestion on how I can stop the madness? I have already tried the /etc/security/msec/security.conf file and have not found a valid setting for having it ignore this issue. Suggestions? -- Albert E. Whale - CISSP http://www.abs-comptech.com -- ABS Computer Technology, Inc. - ESM, Computer Networking Specialists Sr. Security, Network, and Systems Consultant Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec changes Mailman perms
On June 2, 2002 23:24, Albert E. Whale wrote: I'm using LM 8.2 (new install), and running several mailing list. I have grown to like MailMan, a GNU tool. At msec 3 4 I am continually having to reset the /home/mailman perms back to 02775. Does anyone have a suggestion on how I can stop the madness? I have already tried the /etc/security/msec/security.conf file and have not found a valid setting for having it ignore this issue. Suggestions? The following paragraph from http://www.mandrakesecure.net/en/docs/msec.php should help: If you want to override some permissions, you can do this with the /etc/security/msec/perm.local file. Each level has it's own set of different file permissions for some certain files. If you want to take a look at the defaults for each level, look at the /usr/share/msec/perm.* files. They contain the file name (or directory), the user/group that should own it, and the numeric permissions for the file or directory. Let's say, for example, that you are using level 4 but don't want to have /boot with only 700 permissions, which is the default in level 4. You would create your /etc/security/msec/perm.local file and write in it the following: /boot/ root.root 755 Then you would execute msec (just type msec at the command prompt as root), and if you look at the permissions of the /boot directory now, you will see it is 755, so normal users can look in there. -- Tim C [EMAIL PROTECTED] Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
[expert] msec - chage output
Hi When cron.hourly is run on my machine, I get an email telling me:- msec: unable to parse chage output This seems to be generated from /usr/share/msec/libmsec.py after trying to: cmd = '/usr/bin/chage -M %d -I %d %s' % (max, inactive, entry[0]) ret = commands.getstatusoutput(cmd) I wondered if, because I hadn't set any expiry times for passwords on my system, this is where the error message was coming from. Setting expiry times though didn't help. Anyone point me in the right direction. The hourly mails are getting a little irritating. Redirecting them to dev/null seems a chickens way out :) -- 0 Dave Naylor | [---] [EMAIL PROTECTED] Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec - chage output
At 06:24 AM 5/6/02, Dave Naylor wrote: Hi When cron.hourly is run on my machine, I get an email telling me:- msec: unable to parse chage output This seems to be generated from /usr/share/msec/libmsec.py after trying to: cmd = '/usr/bin/chage -M %d -I %d %s' % (max, inactive, entry[0]) ret = commands.getstatusoutput(cmd) I wondered if, because I hadn't set any expiry times for passwords on my system, this is where the error message was coming from. Setting expiry times though didn't help. Anyone point me in the right direction. The hourly mails are getting a little irritating. Redirecting them to dev/null seems a chickens way out :) Dave, This issue has been addressed here and a patch was posted to this list. There's a mismatch between new user entries created by webmin, how chage processes the entries, and how msec processes the output of chage. There's a patch for msec so that it will accept chage's output. Look for a message from 3/30 titled msec vs. webmin - and a patch. HEY MANDRAKE PEOPLE! HOW ABOUT RELEASING THE FIX FOR MSEC ! This is at least the second query about this same issue since I generated the patch over a month ago. David Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec - chage output
Hi On Monday 06 May 2002 12:18, David Relson wrote: msec: unable to parse chage output This issue has been addressed here and a patch was posted to this list. There's a mismatch between new user entries created by webmin, how chage processes the entries, and how msec processes the output of chage. There's a patch for msec so that it will accept chage's output. Look for a message from 3/30 titled msec vs. webmin - and a patch. What I found after posting my message was that I'd set account expiry dates rather than password expiry. Setting password expiries via console using chage has made the problem go away. /me makes mental note, dont be so lazy and use the console more :) -- 0 Dave Naylor | [---] [EMAIL PROTECTED] Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
[expert] MSEC - edit perm.xx or create perm.local?
I have a single machine, no local network, with a broadband (cable modem) connection. Using msec,level 3, which uses a default umask of 022. Is there any reason to create a perm.local file rather than simply edit the settings in the /usr/share/msec/perm.xx files? I want to change the umask for the entire /mnt/windows tree to allow rwx for all local users. Currently it is controlled in perm.3 by (I think) /mnt/ root.root 755 so could I just add /mnt/windows/* root.windows770 to give rwx access to local users of the group windows and wall off as far as possible all access to someone who managed a remote login? If not, a brief explanation of why would be greatly appreciated, along with a pointer to further explanation. And a second question. When I get the household network up I will be using SNF, smoothwall, or something similar. Should each of the local machines continue to use msec, will it be unnecessary, or can I obviate msec by running something else on the router? Fred Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
[expert] msec vs. src.rpm
Greetings, I've noticed that when I build from a src.rpm, there are a lot of files with user and group ids which are not valid for my system. For example, ntp-4.1.1-1mdk.src.rpm gives me files with user 427 and group 6011. While I don't really mind these files, msec _will_ complain and _that_ I do mind. I can always run chown root.root /usr/src/RPM/BUILD/ntp-4.1.1 to change the ids, but wonder if there is a more elegant want to do this? Thanks. David Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
[expert] msec vs. kernel-source
Greetings,
With msec set to level 3 and above, RPM_CHECK is turned on. This caused
rpm -V to run, which isn't a bad thing.
However, the kernel-sources package contains several hundred generated
files. ALL of these files show up as changes on my system since I have
compiled my own kernel. Specifically, I see 224 .depend files and a few
others.
Below is a patch to remove the .depend files.
David
**
--- ./msec-0.20/cron-sh/security.sh Tue Mar 5 23:11:58 2002
+++ ./msec-0.20.1/cron-sh/security.sh Fri Apr 12 08:23:17 2002
@@ -169,7 +169,7 @@
rpm -qa --qf %{NAME}-%{VERSION}-%{RELEASE}\t%{INSTALLTIME}\n |
sort ${RPM_QA_TODAY}
rm -f ${RPM_VA_TODAY}.tmp
-nice --adjustment=+19 rpm -V `cut -f 1 ${RPM_QA_TODAY} | grep -v
'^dev-[0-9]'` | grep '^..5' | sort ${RPM_VA_TODAY}.tmp
+nice --adjustment=+19 rpm -V `cut -f 1 ${RPM_QA_TODAY} | grep -v
'^dev-[0-9]'` | grep '^..5' | grep -v /.depend$ | sort ${RPM_VA_TODAY}.tmp
grep -v '^.c.' ${RPM_VA_TODAY}.tmp | sed 's/^...//'
| sort ${RPM_VA_TODAY}
grep '^.c.' ${RPM_VA_TODAY}.tmp | sed 's/^...//' |
sort ${RPM_VA_CONFIG_TODAY}
rm -f ${RPM_VA_TODAY}.tmp
David Relson Osage Software Systems, Inc.
[EMAIL PROTECTED] Ann Arbor, MI 48103
www.osagesoftware.com tel: 734.821.8800
Want to buy your Pack or Services from MandrakeSoft?
Go to http://www.mandrakestore.com
Re: [expert] msec typo
Damian wrote: El vie, 05-04-2002 a las 12:56, David Relson escribió: The word Writeable is incorrectly spelled. It should be Writable. i'm sure when i get hacked, the hacker will correct the typos in my world-writable files ;oP see ya. Damian actually, it would be more correct to say 'writeable' is a misspelling of word 'writable'. but then, hackers know that. ;) tc,hago. g . -- think green... save a tree, save a life, save time, save bandwidth, save storage. send email, text/plain - disable pgp/gpg/geek code =+= if you are proud to be an american, then buy made in america. Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec typo
At 01:57 AM 4/6/02, you wrote: Damian wrote: El vie, 05-04-2002 a las 12:56, David Relson escribió: The word Writeable is incorrectly spelled. It should be Writable. i'm sure when i get hacked, the hacker will correct the typos in my world-writable files ;oP see ya. Damian actually, it would be more correct to say 'writeable' is a misspelling of word 'writable'. but then, hackers know that. ;) You got me! I expressed it poorly. I think I wanted 'Writeable' is an incorrect spelling Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec typo
David Relson wrote: You got me! I expressed it poorly. I think I wanted 'Writeable' is an incorrect spelling lol. i guess that is why what is said about hind and foresight. anyway, if you keep a sharp eye, you will note that there are other progs that have 'typos'. tc,hago. g . -- think green... save a tree, save a life, save time, save bandwidth, save storage. send email, text/plain - disable pgp/gpg/geek code =+= if you are proud to be an american, then buy made in america. Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
[expert] msec typo
Greetings, msec says Security Warning: World Writeable files found : at the beginning of thee messages it logs to /var/log/boot.log. The word Writeable is incorrectly spelled. It should be Writable. David David Relson Osage Software Systems, Inc. [EMAIL PROTECTED] Ann Arbor, MI 48103 www.osagesoftware.com tel: 734.821.8800 Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
[expert] msec patch [ was: world writeable files]
At 11:18 AM 4/5/02, you wrote: Or better yet, is there a way to get the security check to ignore sockets (which most of these are)? Below is a patch that excludes sockets (and also replaces a numeric value by the proper named constant (MACRO)). Hopefully it can get added to 8.2 and cooker. David --- /usr/src/RPM/BUILD/msec-0.20/src/msec_find/orig/find.c Tue Apr 18 12:30:51 2000 +++ /usr/src/RPM/BUILD/msec-0.20/src/msec_find/find.c Fri Apr 5 11:57:42 2002 -107,7 +107,7 /* * Is world writeable check. */ - if (sb-st_mode 0002) + if ((sb-st_mode S_IWOTH) !S_ISSOCK(sb-st_mode)) fprintf(writeable_fd, %s\n, file); /* Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec typo
El vie, 05-04-2002 a las 12:56, David Relson escribió: Greetings, msec says Security Warning: World Writeable files found : at the beginning of thee messages it logs to /var/log/boot.log. The word Writeable is incorrectly spelled. It should be Writable. David i'm sure when i get hacked, the hacker will correct the typos in my world-writable files ;oP see ya. Damian Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
[expert] msec vs. webmin - and a patch
Greetings,
If I used webmin to add a user, the next time msec runs it complains:
msec: unable to parse chage output
I took a look at why this happens and found a fix, which is shown
below. This fix has already made it into cooker. Any chance of an 8.2 update?
Thanks.
David
*
When webmin adds a user, the entry in /etc/shadow looks like:
usr1:$3$37105428$38J/slmiH0OJ6iRnZKZp9.:11772::
/usr/share/msec/libmsec.py expects to have a number as the maximum field,
as in:
usr2:$3$37105428$38J/slmiH0OJ6iRnZKZp9.:11772::9
Here's the output from chage for these two users:
[root@osage samba]# /usr/bin/chage -l usr1
Minimum:-1
Maximum:-1
Warning:-1
Inactive: -1
Last Change:Mar 26, 2002
Password Expires: Never
Password Inactive: Never
Account Expires:Never
[root@osage samba]# /usr/bin/chage -l usr2
Minimum:-1
Maximum:9
Warning:-1
Inactive: -1
Last Change:Mar 26, 2002
Password Expires: Never
Password Inactive: Never
Account Expires:Never
The line Maximum:...9 is recognized by object maximum_regex. Adding
a regular expression to recognize Maximum:...-1 allows libmsec.py to
successfully process the lines in /etc/shadow generated by webmin.
I've made this change to my copy of libmsec.py and msec is happy. Here's
the patch:
[root@osage msec]# diff -u libmsec.py.orig libmsec.py
--- libmsec.py.orig Fri Mar 8 13:41:21 2002
+++ libmsec.py Mon Mar 25 23:35:08 2002
-544,6 +544,7
atallow.replace_line_matching('root', 'root', 1)
maximum_regex = re.compile('^Maximum:\s*([0-9]+)', re.MULTILINE)
+minimum_regex = re.compile('^Maximum:\s*(-1)', re.MULTILINE)
inactive_regex = re.compile('^Inactive:\s*(-?[0-9]+)', re.MULTILINE)
# TODO FL Sat Dec 29 20:18:20 2001
-577,7 +578,7
ret = commands.getstatusoutput(cmd)
_interactive and log(_('got current maximum password
aging for user %s with command \'%s\'') % (entry[0], cmd))
if ret[0] == 0:
-res = maximum_regex.search(ret[1])
+res = maximum_regex.search(ret[1]) or
minimum_regex.search(ret[1])
res2 = inactive_regex.search(ret[1])
if res and res2:
current_max = int(res.group(1))
Want to buy your Pack or Services from MandrakeSoft?
Go to http://www.mandrakestore.com
Re: [expert] msec and xsane
--- On Thu 03/28, Rob Gillen <[EMAIL PROTECTED]> wrote: > If you aren't sure which kernel you are using, trying running 'uname > -r' on the command line. You are using the secure kernel if it turns up > 2.4.18-6mdk-secure. If msec doesn't change it, then it may have been an > installation thing. Thanks everyone, I'll check the URL at mandrakesecure and see if there is something I am missing. And while I'm at it, I'll do the uname command. Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec and xsane
--- On Wed 03/27, Rob Gillen <[EMAIL PROTECTED]> wrote: > I may be wrong, but it probably has something to do with Mandrake >using > the secure kernel. It removes some userspace functionality for >safety. I booted into the enterprise kernel though... And the changes from higher to high and vice versa happen instantly (scanner doesn't work then does), if they are actually changing which kernel is to be used wouldn't I need to reboot, because you can't change the kernel in use without rebooting as far as I know (I think kernel updates are the only reasons I ever HAD to reboot). That's why I was thinking it may be something with permissions of whether a program can or cannot use certain hardware (/dev/sg0 in this case). I have no clue... Is there any very detailed document explaining what changes happen when switching security levels in msec? > gikoreno wrote: > > > Hi everyone, > > > > I just checked the newbie and expert lists, and couldn't find > anything > > that answered this question... > > > > I just installed Mandrake 8.2, but kept my previous Mdk 8.1 /home > > partition. I used to have xsane working, and I ran scannerdrake and I > > > can't seem to get the scanner working with msec on "Higher. > > > > I haven't figured out as of yet what the problem is, but I was > > suspecting it's something that has to do with permissions because: > > > > - regardless what msec is set to, if I run sane-find-scanner as root, > > > my scanner is found at /dev/sg0 > > > > - if I set the security settings to "standard" everything > works (i.e. > > xsane works too) It will also work if I set msec to "High" > > > > - if I set it back to higher, although I can "find" the > scanner with > > sane-find-scanner as root, I cannot open xsane (even as root) because > > > "xsane: no devices available". > > > > Where could I make the permissions change to enable the scanner for > > all users, but keep the system on msec "Higher"? > > > > Thanks in advance! > > > > > > > > > > > > >Want to buy your Pack or Services from MandrakeSoft? > >Go to http://www.mandrakestore.com > > > > > > > Want to buy your Pack or Services from MandrakeSoft? > Go to http://www.mandrakestore.com > Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec and xsane
Is there any very detailed document explaining what changes happen when switching security levels in msec? This may help: http://www.mandrakesecure.net/en/docs/msec.php -- Tim C Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec and xsane
If you aren't sure which kernel you are using, trying running 'uname -r' on the command line. You are using the secure kernel if it turns up 2.4.18-6mdk-secure. If msec doesn't change it, then it may have been an installation thing. gikoreno wrote: --- On Wed 03/27, Rob Gillen wrote: I may be wrong, but it probably has something to do with Mandrake using the secure kernel. It removes some userspace functionality for safety. I booted into the enterprise kernel though... And the changes from higher to high and vice versa happen instantly (scanner doesn't work then does), if they are actually changing which kernel is to be used wouldn't I need to reboot, because you can't change the kernel in use without rebooting as far as I know (I think kernel updates are the only reasons I ever HAD to reboot). That's why I was thinking it may be something with permissions of whether a program can or cannot use certain hardware (/dev/sg0 in this case). I have no clue... Is there any very detailed document explaining what changes happen when switching security levels in msec? gikoreno wrote: Hi everyone, I just checked the newbie and expert lists, and couldn't find anything that answered this question... I just installed Mandrake 8.2, but kept my previous Mdk 8.1 /home partition. I used to have xsane working, and I ran scannerdrake and I can't seem to get the scanner working with msec on Higher. I haven't figured out as of yet what the problem is, but I was suspecting it's something that has to do with permissions because: - regardless what msec is set to, if I run sane-find-scanner as root, my scanner is found at /dev/sg0 - if I set the security settings to standard everything works (i.e. xsane works too) It will also work if I set msec to High - if I set it back to higher, although I can find the scanner with sane-find-scanner as root, I cannot open xsane (even as root) because xsane: no devices available. Where could I make the permissions change to enable the scanner for all users, but keep the system on msec Higher? Thanks in advance! Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
[expert] msec and xsane
Hi everyone, I just checked the newbie and expert lists, and couldn't find anything that answered this question... I just installed Mandrake 8.2, but kept my previous Mdk 8.1 /home partition. I used to have xsane working, and I ran scannerdrake and I can't seem to get the scanner working with msec on "Higher. I haven't figured out as of yet what the problem is, but I was suspecting it's something that has to do with permissions because: - regardless what msec is set to, if I run sane-find-scanner as root, my scanner is found at /dev/sg0 - if I set the security settings to "standard" everything works (i.e. xsane works too) It will also work if I set msec to "High" - if I set it back to higher, although I can "find" the scanner with sane-find-scanner as root, I cannot open xsane (even as root) because "xsane: no devices available". Where could I make the permissions change to enable the scanner for all users, but keep the system on msec "Higher"? Thanks in advance! Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec mail (twice)
Thanks a lot, this was due to an error in the config file and also a domain name problem. With root@localhost everything works fine now. Francois At 16:54 23/02/02 +0100, you wrote: Look in /etc/security/msec/security.conf Maybe this update has corrupted or changed this config file. In this file you should find: MAIL_WARN=yes MAIL_USER=root And you must look in /etc/postfix/aliases to see who is receiving the root mail. Saludos óscar. El sáb, 23-02-2002 a las 13:42, FL escribió: Of course the mail system is running on two servers without any problems. Because this is the same situation on two MDK box I'm running. I really think it has been done via an update, but don't know wich one. Francois Le Samedi 23 Février 2002 11:18, Oscar a écrit : El sáb, 23-02-2002 a las 10:52, FL escribió: I was used to receive mail from the cron.daily check made by msec. For a few weeks : nothing happens, I can read the msec messages in /var/log, but no mail at all. Any idea ? Francois Is the mail subsystem running properly? saludos óscar. -- .-. oo| /`'\ Usuario de Linux Registrado #227443 (\_;/) http://counter.li.org/ Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
[expert] msec mail (twice)
I think this a _really_ a MDK question... -- Message transmis -- Subject: [expert] msec mail Date: Fri, 22 Feb 2002 14:35:54 +0100 From: FL [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hi! I was used to receive mail from the cron.daily check made by msec. For a few weeks : nothing happens, I can read the msec messages in /var/log, but no mail at all. Any idea ? Francois --- Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec mail (twice)
El sáb, 23-02-2002 a las 10:52, FL escribió: I think this a _really_ a MDK question... -- Message transmis -- Subject: [expert] msec mail Date: Fri, 22 Feb 2002 14:35:54 +0100 From: FL [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hi! I was used to receive mail from the cron.daily check made by msec. For a few weeks : nothing happens, I can read the msec messages in /var/log, but no mail at all. Any idea ? Francois Is the mail subsystem running properly? saludos óscar. -- .-. oo| /`'\ Usuario de Linux Registrado #227443 (\_;/) http://counter.li.org/ Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec mail (twice)
Of course the mail system is running on two servers without any problems. Because this is the same situation on two MDK box I'm running. I really think it has been done via an update, but don't know wich one. Francois Le Samedi 23 Février 2002 11:18, Oscar a écrit : El sáb, 23-02-2002 a las 10:52, FL escribió: I was used to receive mail from the cron.daily check made by msec. For a few weeks : nothing happens, I can read the msec messages in /var/log, but no mail at all. Any idea ? Francois Is the mail subsystem running properly? saludos óscar. Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
Re: [expert] msec mail (twice)
Look in /etc/security/msec/security.conf Maybe this update has corrupted or changed this config file. In this file you should find: MAIL_WARN=yes MAIL_USER=root And you must look in /etc/postfix/aliases to see who is receiving the root mail. Saludos óscar. El sáb, 23-02-2002 a las 13:42, FL escribió: Of course the mail system is running on two servers without any problems. Because this is the same situation on two MDK box I'm running. I really think it has been done via an update, but don't know wich one. Francois Le Samedi 23 Février 2002 11:18, Oscar a écrit : El sáb, 23-02-2002 a las 10:52, FL escribió: I was used to receive mail from the cron.daily check made by msec. For a few weeks : nothing happens, I can read the msec messages in /var/log, but no mail at all. Any idea ? Francois Is the mail subsystem running properly? saludos óscar. -- .-. oo| /`'\ Usuario de Linux Registrado #227443 (\_;/) http://counter.li.org/ Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
[expert] msec mail
Hi! I was used to receive mail from the cron.daily check made by msec. For a few weeks : nothing happens, I can read the msec messages in /var/log, but no mail at all. Any idea ? Francois Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
