Re: Orthogonal Code and Security

Would not the .htaccess approach from Apache work in this specific situation? Namely, by default, assume that a directory to be written to is blocked, but by the introduction of a dot file that the code can detect, you can either simply say that existence is merely enough to ensure access, or set up some complicated language that can determine security levels on the fly? In this case, you are moving the security configuration out of the program and into the file space.

But I'm sort of confused as to what you are considering orthogonal and secure. In your example, you have a list of dirs, and you say that this isn't orthogonal because when you move the dir tree or add a new dir, you also have to update the code, so that's two placed to change. But on the other hand, you say that moving any security out from the code and elsewhere is insecure. I don't see how anything that operates at the file level cannot do the latter. You have to decide where you are going to pack the security features; if you do it in perl, you lose orthogonality, if you do it on the file system, you lose 'security' by your thoughts (please correct me if I'm wrong).

IMO, the best way to solve the problem above is to use a hash to point the keys to the directories that may be written to; the keys are the only things sent via CGI, while the values (untainted) and the only things used to create or write files. Your security configuration is in perl, but as you claim, this is not necessarily orthogonal.

Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain

Comment on Re: Orthogonal Code and Security

Replies are listed 'Best First'.
(Ovid) Re(2): Orthogonal Code and Security by Ovid (Cardinal) on May 02, 2001 at 22:28 UTC
Masem wrote: You have to decide where you are going to pack the security features; if you do it in perl, you lose orthogonality, if you do it on the file system, you lose 'security' by your thoughts (please correct me if I'm wrong). You understood me correctly. My thoughts on security are pretty simple: if they're out to get you, paranoia makes good sense. Who are 'they'? Anyone who's not Ovid. What does 'out to get you' mean? Doing anything which may affect my code and what it does, whether or not it's intentional. I try to be ultra-paranoid when I write a CGI script. As a result, I don't want to trust anything outside of my code. Of course, I can't stop another programmer from going in an changing my code, but I don't want my code to be dependant upon what others have done. I suppose it's just finding a balance between what's reasonable and what's so frickin' stupid (perhaps my code?) that I deserve to be shot for writing it. Realizing that operating systems often have a certain level of security built into them, perhaps I can rely on this. On the other hand, I have a significant weakness in that I don't understand much about the operating systems themselves, or how they are set up. I tend not to want to rely on something that I don't know well. Hmm... obviously I need to learn more about this area. Cheers, Ovid Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.	[reply]
Re: (Ovid) Re(2): Orthogonal Code and Security by Masem (Monsignor) on May 02, 2001 at 22:42 UTC
One of the things that I thought about this is that generally, security and orthogonality cannot coexist, or better stated: (level of security) x (level of orthogonality) = constant. A more secure system is going to have multiple checkpoints, which will defeat the purpose of orthgonality (though not the ability of code reuse). Orthogonal code will be less secure because of the lack of interaction between security mechanism. Go back to the car example: most automatics will not let you start the engine if the car is not in park, which means any orthogonality between the ignition and the transmission is gone. But, because of this, there is an increase in 'security' in that you won't be stripping gears or wearing the engine because of improper usage of either system. So the problem of security vs orthogonality comes down to the programmer (and possibly job description) to decide where they want to be; in your (Ovid's) case, you want to be ultra-strict, which means multiple checks, which means that systems need to be less orthogonal to make everything work. Someone else might feel that because of multiple programmers that are working on a project, orthogonality is an absolute must, and security measures may fall due to this. There's no right or wrong answer to "how secure is secure" or "how orthogonal is orthogonal"; it's all going to depend where the emphasis is to be placed by the programmer. So when faced with problems like these, the best way to approach them is exactly how your test case did: you ask a number of people for opinions: since everyone has a different idea where security/orthogonality should be, you'll get a number of solutions that sit along the curve given above, and you can choose a solution that is near the point where you desire. Dr. Michael K. Neylon - mneylon-pm@masemware.com \|\| "You've left the lens cap of your mind on again, Pinky" - The Brain	[reply]
Re: Re: Orthogonal Code and Security by MeowChow (Vicar) on May 02, 2001 at 23:25 UTC
While more flexible, the .htaccess approach is intrinsically riskier than Ovid's, because you must pass a directory or file derived from untainted user data to a system call (ie. opendir, or open). This means you have to carefully consider all classes of valid input versus invalid and potentially dangerous input. From a security perspective, it's preferable to have a simple mapping of user input to prearranged file locations. MeowChow s aamecha.s a..a\u$&owag.print	[reply]
(kudra) Re(3): Orthogonal Code and Security by kudra (Vicar) on May 03, 2001 at 12:59 UTC
Hmm, I saw that suggestion working in a different manner: searching directories (either on the fly or updating at intervals depending on number of directories and how rapidly the system needs to respond to changes), and building a paths data structure from that, which could then be used to verify the user-input as in Ovid's example.	[reply]