I realize that this is a matter or preference (as is this entire answer), but I'm a bit scared of your /lib directory. Are these modules or libraries specific to the app? Do you only use them in this app? I guess it's OK if that's true (since you want to avoid multiple copies of he same module in different directories) but are you sure that they have no use in other apps now or in the future? Just as a matter of organization, I like to store ALL of my modules in one place, namely the /..somewhere..../perl/ directory with the rest of the modules, perhaps in your own /personallibs directory. I just like to make sure that I can easily find and link my modules without searching or pushing more bloat onto @INC (which just leads to unmaintainabliity). If you are not a superuser on your machine, then I would strongly suggest creating your own mini perl directory filled with CPAN modules not normally installed and your personal libraries. That way, you are always certain where you can load up that library that you've used before. I notice that you are organizing well, but wonder why. Few programmers are truly gifted in the sense of organization and I'm sure that future program maintainers will thank you for the easy job of being able to know what's going on in your code. Along the lines of security- your Apache configuration is far more crucial than throwing stuff into directories to separate them out and saying "(nobody) has access to this directory only" when you really should be limiting file by file, preferably with suffix notation. It's too easy to accidentally throw, let's say, a .pm module into cgi-bin and make it world readable. Instead, just block it out with an Order deny,allow for everything except .html, .shtml, .cgi and anything else you are serving.

AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.

AgentM,

Thanks for the reply. Point by Point:

...I'm wondering what all the hubbub is about.

During a chatterBox discussion the same day, merlyn very clearly mentioned security risks associated with the original design. (See Understanding Secure File Organization for a diagram.) This made me nervous, since I was trying to retrofit the sample to be more secure, a process I am still learning.

I originally thought, as you point out, that setting permissions was adequate. The warning, along with some of the follow-up commentary suggested that it wasn't. So, I searched PM for security and found several different discussions about various risks but fewer discussions concerning solutions.

Thus, I'm trying to collect ways to solve potential security risks, as well as write perl applications that are easier to maintain and move. (Thank you for noticing, BTW).

I have read the FAQ's, several books, and many, many links. Little appears to discuss architecture, that is, layout out an application with an eye for security.

One comment that stuck, though, was that one way to reduce the information that can be potentially exploited is to reduce the amount of information publicly available. My theory, then, is that by compartmentalizing code into specific "need to know" areas, I can reduce the number of visible holes.

I hope this isn't security through obscurity, as that appears to be a Bad Thing, along the lines of Cargo Cult Programming and other things to avoid. My request for wisdom is to make sure I'm on the right track.

...if you configure Apache correctly, the directories make no difference.

Would you mind expanding on this a bit? What are some things to look for? I presume it's more than:

• Avoiding symbolic links
• Ensuring IncludesNOEXEC is active for the httpd\ directory
• Making sure that ScriptAlias points to a directory *outside* of httpd\.
• Setting permissions of CGI scripts to 755.

Again, I'm trying to a) learn and b) start a discussion that documents the security practices of other Monks, especially the ones with the most experience (pun, intended).

...making more directories does not improve your security without obscuring it (permission bit mask confusion!)

Permission bit mask confusion?

...I'm a bit scared of your /lib directory. Are these modules or libraries specific to the app? Do you only use them in this app?

Again, just application libraries and personal toolkit libraries that aren't yet in a state to be shared. The toolkit stuff will (I hope) eventually get to the point where they're be shared across multiple applications, but until they're at that point, I confess I am duplicating a few functions here and there. By design It's a way for me to experiment with making what I think will be common routines, while buying me a little bit of time to a) make sure I'm not reinventing the wheel and b) making sure that they really should be toolkit routines.

...I notice that you are organizing well, but wonder why. Few programmers are truly gifted in the sense of organization and I'm sure that future program maintainers will thank you for the easy job of being able to know what's going on in your code.

In part because I have, over the course of my career, inherited too many poorly organized applications. I don't expect to spend my entire career with this employer, so I would like my stuff to be easily--and, perhaps more importantly--quickly understood by the poor sap who has to maintain my legacy code. Also, it's a sanity check for when *I* have to maintain the system in a few months/weeks/years/etc.

...just block it out with an Order deny,allow for everything except .html, .shtml, .cgi and anything else you are serving.

Hm. I hadn't thought of that. *ponder*

How does this strike you? Use (and allow) .cgi for the scripts called by the HTML forms, but use (and deny) .pl for the "kit" code. Is that an effective measure? Or have I forgotten something or inadvertently stumbled on another obscurity or cargo cult meme?

Hey, glad to be of help. My thoughts are pretty much entirely centered around making sure your Apache configuration is set2go FIRST before you get fuddy-duddy. What I mean by "permission set mask" is that it might get confusing- which users may have access to which directories, etc. If you don't want (nobody) to read the file, simply set it in Apache- it's much more readable and much more integrable (since you'll be grouping all of your security stuff into one convenient Apache .conf instead of some security measures here, some there...) Your directory structure, as I said, has little to do with "security" per se- all you really need to do is have a meaningful Apache configuration. Every directory can have its own .htaccess file as well as other configuration mechanisms. You can, of course, look more into this at the Apache FAQ. What I see here is too much time spent on something that may be effective but could have been simplified with a few lines in Apache .conf. By default, I believe, .pl is executed as CGI, so you might want to turn that off or consider renaming your itty-bitty perl libs to .lpl or something. You should definitely change your configuration to serve ONLY files that have a specific suffix- this is the base of webservice security. You may at some point want to throw in some documentation for the program, maybe in the form of a .txt or .doc. You certainly don't want that served out. So use LIMITs in the .conf liberally and your security is ALL set. Remember, it's most useful to the future programmers to look at a .conf rather than scrunge through a potentially large number of directories searching for a permission set. Apache.org has numerous examples of configurations, probably one already that fits your needs to the T. Order deny,allow is your friend and that should be seen multiple times in your .conf. It means, if it's not confirmed to be served- don't serve it. (period)

About your library routines: I obviously don't know enough to make an informed decision about your packages and their future usefulness, but I would still find a centrally located directory of packages infinitely more useful. If you are writing packages of non-reusable code, you're missing the point of OOP- REUSABLE CODE! Reusable code is infinitely more useful than a function-specific package. Even if you have to write a few more lines in the main function, you are saving yourself trouble later by making the package reusable by other layers of programming, especially in the debug phase which is the leech on programmers' brains...well, have fun!


AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.

What are you using for version control? There are many kinds of problems you need to deal with, and security is only one of them.

Personally I would suggest having the data and some local configuration nowhere near your cgi-bin for the simple reason that it is nice to have your cgi-bin under the control of CVS, and you don't want to check all of your data files into CVS! Likewise it is good to have the possibility of per user configuration information safely out of CVS.

A lot of schemes are possible, but the simple step of using some versioning scheme on important files saves many headaches, makes it much easier for developers to work in close cooperation. Just remember to commit and update early and often...

tilly,

Excellent point, one that I had factored out of the posted questions in an attempt to simplify the discussion.

The current plan is to treat the entire site as a development project, with server configuration, page development, client scripting, and server scripting as a single project. Thus, the "root" folder gets version controlled.

While there may be some disagreement on that approach, I believe that treating each element as part of the whole helps ensure the end results are closer to what the user asked for...and not what we chose to give them... ;-)

Several thoughts.

How much data do you have? One nice thing about CVS is being able to check out many copies at once. This gets very prohibitive on disk space.

How fast does it change? Remember that CVS archives the entire history of files. If your data changes fairly often, this archive can get huge.

When everything is released, do you want the release schedule for the website to be tied to the refresh of your data? I would guess not. If you don't then you don't want the data to be mingled in with the code versioning system. If you do, that is a big restriction that you should be clear about up front.

Speaking of which, your current development environment will be your default maintainance environment. Stop and think about that in solving these configuration questions. You are likely to live with this solution in other phases of your project and your answer should remain good.

For these and other reasons I would suggest that you use some sort of standard incremental backup system for your data files, and not have data in your version control system. Otherwise you are imposing several subtle restrictions on your clients. If they want to basically have a static, "About us" home page, the restrictions will not matter. If they want to have things like bulletin boards, news articles, file downloads, etc then the restrictions will likely turn out to be unacceptable.

Also, don't get too uptight about the security thru obscurity thing. Given that you are doing your best to secure it properly, throwing obscurity at it _too_ can't ever hurt much. The point is not to _depend_ on it!

Oh, and tilly's point about CVS is well considered to... It is fair to ask why have non-code/html in the code/html trees. The data you may wish to move down out of the apache tree completely, or at least lower.

--
$you = new YOU;
honk() if $you->love(perl)