in reply to Restricted' data, a clarification
in thread 'Restricted' data, an additional security mechanism for Perl.

I'll still going to say I don't understand the motivation, but this makes your goals more clear. I don't have a vested interest in fighting this one, but I am enjoying playing devil's advocate...

So, if the goal is to keeping newbie programmers from using a variable without first running a subroutine on the variable, what is to say they can't use a weak subroutine to "clean" a variable? 

filter CreditCard, sub { return $_ };

[download]

Also, what is to prevent someone from just passing around the gateway variable as a "key" within the code? 

sendToEvil(DB,$passwd)

[download]

I could be missing some of the finer points, but essentially my point is "a lock is no good if the key is under the door mat". It seems the key is under the door mat. If not, I'm darn sure I could get that key fairly easily, and that by definition of the facilities employed in implementing this, isn't not really a security measure at all.

Now some languages have private variables, and this is marginally useful if your fear is someone printing a password. It seems we would go further by trying to find a way to write private variables that can only be read from certain packages. However, this not say some one can't modify the original code (or perform other exploits) to defeat this "security".

So why don't we trust the code we are running? Is this part of a plugin architecture where arbitrary users can upload code? If not, don't allow that. Otherwise, isolate your credit card and password items into modules no folks have value tampering with. If you really can't trust your fellow coders on a project, you might (possibly) be able to write FETCH/STORE kind of wrappers that deny access from outside the package. (This is theory, I don't know...).

Essentially security should deal with external sources getting at data -- other users, other programs, networked or not. When you can't trust your own code, that's sandboxing, and is a different problem. Calling this security, at least in my eyes, gives us a false illusion of being secure. This is just a very small piece...helping to know that you have not handled data loosely throughout your app.

For one who is teaching security, start with the basics. Network security. Open ports. Packet sniffers. Plaintext data. Encoding is not Encryption. Injections. SSL without keys and key exchange. DOS vulnerabilities. Cross-site scripting and SQL vulnerabilities. Changing HTML forms to alter important fields. Spoofing and IP games (arp). Man-in-the-middle. Local security. Permissions. Uploading and executing code to gain local access. Only once that you have stopped all-of-the-above is the "restricted code" module really important. All of the others have higher gains and are more likely to be exploited by 'evil'.

I'm not a security expert by any grounds, but where I work I've seen and fixed numerous holes in our mystery app (FYI -- it's not Perl) since I'm one of few that has interest in finding/closing them. The most obscene was encoding passwords BASE64 (plaintext-equivalent) and leaving the file permissions as 655! Local socket exploits (non-root user being able to connect and manipulate root daemon) were also found. We also used to use a lot of plaintext network traffic. It's a big deal, and you've got to look everywhere to clean up what most folks don't know to think about. This is all white-hat easy stuff too... I'm sure it can get a lot more evil/complicated if someone really wanted in to our app. In conclusion, we aren't even close to secure now...but it's getting better.

Replies are listed 'Best First'.
Re: Re: Restricted' data, a clarification
by jarich (Curate) on Feb 12, 2004 at 05:16 UTC
    So, if the goal is to keeping newbie programmers from using a variable without first running a subroutine on the variable, what is to say they can't use a weak subroutine to "clean" a variable? 
    filter CreditCard, sub { return $_ };

    [download]

    Exactly the same thing that stops a newbie programmer from using the regular expression /(.*)/ to untaint their variables. Nothing. Except if you saw that kind of untainting going on, you'd be even less willing to trust their code.

    This idea isn't about protecting newbies from themselves. It's not about trusting fellow programmers or not trusting them. It's not about preventing someone from editing your code or passing around the "gateway variable" (although I don't quite understand what you meant by that). There's no point in building in "security" like this into scripts that other people can edit. Particularly since all of this could be turned off by commenting out or deleting whatever turned it on.

    This idea is about assisting experienced, professional coders in their coding. It's about making sure that we don't do stupid things like print out a variable, made up of data that should be restricted, to a log file because it's 3am in the morning and the coffee's worn off.

    Yes the key is under the mat. It's under the mat in taint checking too. A perfect coder shouldn't ever need to turn on taint checking because that coder would always clean variables coming in from tainted sources. However, that's no excuse for not turning on taint checking anyway. It doesn't cost a lot and is important because that perfect coder's code might be edited by me sometime in the future. I'm not perfect.

    Essentially security should deal with external sources getting at data -- other users, other programs, networked or not. When you can't trust your own code, that's sandboxing, and is a different problem.

    I can trust my code to have bugs in it. I can trust that some of my code will grow past 2000 lines long and that I may not be the sole maintainer of it. I can't always trust that this innocuously named variable $string hasn't collected some restricted data along the way that I shouldn't be printing out to STDERR. It would be nice to have something assist me by keeping track of that information at a lower level, and dying or filtering the string when I attempt to print it to a log file I can't easily truncate. This isn't sandboxing in the sense that I understand sandboxing.

    Does this help explain my reasoning behind our suggestion?

    jarich

[reply]
[d/l]
[select]
Re: Restricted' data, a clarification
by Abigail-II (Bishop) on Feb 12, 2004 at 09:23 UTC
    I could be missing some of the finer points, but essentially my point is "a lock is no good if the key is under the door mat". It seems the key is under the door mat.
    It's not a lock. It's not intended to prevent malice. A programmer could always remove the 'restrict' calls, or add calls as to allow sensitive data to go out on evil channels.

    Tainting isn't a lock either. "use strict;" isn't a lock. Nor is "use warnings;". They are like safety belts. Those aren't locks either. They help you prevent doing damage.

    Abigail

[reply]

      Fair enough. Safety belts are good. I understand now.

      But if I may, I'd like to polish up the API quite a bit. This should be equivalent in goal and allows for the restricting code to be given by the restrictor, not the one using the restricted data. So this is much more safe and allows for writing the protection routine only once.

      May I suggest: 

      use Restricted;
RESTRICT $creditCard, sub { someMangling($_); };
print $creditCard;  # only shows last four
print UNRESTRICT($creditCard); # prints whole number
print $creditCard;  # var is restricted here as well

      [download]
      AND also (if you want death) you have choices: 
      use Restricted;
RESTRICT $creditCard, sub { die "locked variable!" };
print $creditCard;  # KABOOM!
print UNRESTRICT($creditCard); # OK

      [download]

      Seems much more straight forward as an API to me. I could live with (and actually like and use) this interface. Needs to be extended to support non-scalar data structures though, but I suppose restricting references would serve appropriately.

      Comments?

[reply]
[d/l]
[select]

In Section Meditations