On Fri Jun 06, 2003 at 01:37:23PM -0400, Jean-Michel Dault wrote: > > Personally, I liked it. =) But some people do not approve of my proactive > > approach to security. I suppose they like the reactive approach better. > > Why don't we disable /proc? It's pretty insecure... Why don't we patch > pam so we need an 8-digit password with capitals, numbers, punctuation > otherwise it's not accepted? Why don't we disable the autologin feature > that means anyone can access the system without username and password? > Why don't we setup lilo so it has a mandatory password by default?
Well, disabling /proc is impossible... it's kinda necessary. Using cracklib with pam is pretty sufficient to discourage really simple passwords. Disabling autologin is, in my opinion, a good idea. LILO requiring a password for changing boot (ie. using "linux single") would be a good idea as well (for normal bootup, I think it's excessive, but disabling the ability to change boot options is a good thing). > There is a balance between security and convenience. Absolutely. But this is so inconsequential either way, it doesn't really matter to me. I indicated my own personal preference. I've already stated that this hack will not go into updates because changing a config arbitrarily is not a good thing. But cooker? I don't see a problem with it (again, personal opinion). I also don't really see the need for it because, as I indicated before, only stupid people would write a script to expose that information to the world. A good sysadmin would not do this. > There are things you suggested which got into Apache even though I knew > there would be some backlash around it, but that I accepted since most > users take default settings and don't fiddle with them. In this case, it > made sense. Right, and those amounted to more of an issue than this. Can you see I'm not pushing/pressing for this? I am making my own personal views known. To get flamed for that is just silly. =) I have yet to make a recommendation that this is something we need to do. > But taking the function that 99% of people use first when developing a > web site is asking for serious trouble. Which is, again, why I haven't pushed the issue. > As I said, the moment the PHP group accepts this, I'm in, as this will > be covered extensively by the manual, support websites, and howtos. If > you want to be proactive, send a mail to [EMAIL PROTECTED], and see his > reaction ;-) I don't think disabling phpinfo as a function, in stock PHP, is necessary. I do believe that there should be an additional configuration item to limit to whom that can be exposed to, ie: something like php_expose_info = 127.0.0.1 or something along those lines so that in a co-lo setting, an admin can make use of the function (and let others do so as well by using lynx on the machine if they have shell access), but still prevent anyone from accidentally exposing that info to the outside world. As I, also, indicated before, as soon as a fix is available from the PHP group regarding the XSS issue, I'd be more than happy to fix it in updates, but I am not willing to tamper with people's configs arbitrarily. Has it sunk in yet that I am not pushing for this change in cooker? =) -- MandrakeSoft Security; http://www.mandrakesecure.net/ Online Security Resource Book; http://linsec.ca/ "lynx -source http://linsec.ca/vdanen.asc | gpg --import" {FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
pgp00000.pgp
Description: PGP signature
