Date: Sat, 25 Dec 1999 00:56:07 -0700 From: "J.C. Frazier" <wolfman@csocs.com> To: freebsd-isp@FreeBSD.ORG Subject: Re: Apache / FrontPage file permissions Message-ID: <38647897.93EDD30E@csocs.com> References: <199912250531.SAA63592@ducky.nz.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Dan Langille wrote: > One of the issues associated with Front Page extensions is the file > permissions for files within the web. If you don't allow shell access to > your web server, this isn't an issue, but if you do, please read on. I've spent a lot of time on the phone with Microsoft and on their pages. The recommend and I tend to agree with them that if you run the patched apache (apache-fp) that allowing users to ftp and have shell access is fine and will not cause any damage. mod_frontpage has extra security precautions and since in that version the executables aren't in the user's web, it can be restored with one command if anything does happen to those files. However, if you are running the non-patched version of Apache and using FP extensions, executables can be deleted. It is recommended that users have no shell access or ftp access in this case. The only directories for Frontpage webs that should be tightly secured are those such as your root web and top of your user directory and that is to insure other shell customers can not gain access to the same. > In particular, service.pwd contains an encrypted password, which if > obtained could passed to a cracker program. The Fpsrvadm utility can be used to automatically chown and chmod existing content files in a FrontPage-extended web to be owned by a given user. Automatic chown and chmod can be performed when you install the server extensions (using fpsrvadm -operation install) or later (using fpsrvadm -operation chown). These operations set the content to be owned by the user, and they set the FrontPage Server Extensions stub executable files to be SUID. > I've tested this out and it seems to work fine. The only outstanding > issue is the education of shell users that files should not be world > readable. But users being users (not to mention some admins), I think > a script to search for world readable files within the web server file space > is a good idea. It would run daily and report on such files. I've been > given such a script but haven't tried it out yet. The patch to the Apache Web server intercepts each call that the FrontPage client makes to the server extensions executable files. It then performs security checks, sets user ID to the owner of the Web site (thus requiring SUID/SGID operation of the server extensions and the web content), and invokes a centralized copy of the server extensions executable files. <taken from FP online documentation> Frontpage relies on certain file permissions to maintain security over those files. Once you install FP you are not in UNIX world anymore. File permissions do not have a lot of effect since Frontpage is being run by the server, and it's Frontpage along with Apache that's servicing requests. There is a script in the /usr/local/frontpage/version* directory called set_default_perms.sh which will restore the necessary permissions on files to insure Frontpage can read/control them without allowing others to do the same. Anytime you suspect your FP file permissions have been changed you need to run this script. You need to make sure that Frontpage security is dealt with first. When using the patched version, mod_frontpage will not allow visitors to gain access to those important files such as your encrypted services.pwd as long as Frontpage security has been dealt with. The main thing to remember is to make sure you have your AllowOverride set correctly in your httpd.conf so that your .htaccess files are read by the web server. .htaccess files are the key using FP, not file permissions anymore. Also, do not allow your customers to use the same password for their shells as they do for FP. FP has proven to be insecure if not run correctly and there are many many exploits. A malicious person will no doubt try to gain entry into your system trying passwords they may have discovered from a customers FP password files. You can also allow access to Frontpage by IPs for each web. Along with everything above setting IP access restrictions with FPsrvadm is your best bet. Hope this helps, J.C. Frazier > -- > Dan Langille - DVL Software Limited [I'm looking for more work] > The FreeBSD Diary - http://www.freebsddiary.org/freebsd/ > NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ > The Racing System - http://www.racingsystem.com/racingsystem.htm > unix @ home - http://www.unixathome.org/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-isp" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38647897.93EDD30E>