in reply to Re: 'Restricted' data, an additional security mechanism for Perl.
in thread 'Restricted' data, an additional security mechanism for Perl.

Well, it's a matter of upholding the architecture. Nothing more. Some people don't value it, some do. It's the entire "backyard" thing.

For most languages, that type of interpretation gets done at compile time. If you can play with pointers/change the permissions dynamically, it's easy to get around, you are right.


Play that funky music white boy..
  • Comment on Re: Re: 'Restricted' data, an additional security mechanism for Perl.

Replies are listed 'Best First'.
Re: 'Restricted' data, an additional security mechanism for Perl.
by Abigail-II (Bishop) on Feb 09, 2004 at 21:27 UTC
    Huh? This has nothing at all to do with pointers, or changing permission dynamically. You propose a scheme were information isn't available anymore after N uses, to avoid leaking (by accident or on purpose) of sensitive data into forbidden channels.

    I merely point out that that scheme isn't going to work, as the leakage might as well occur before the intended usuage.

    What "upholding the architecture" has got to do with it beats me.

    Abigail

[reply]
      I agree with you 100% on your post about it not protecting the user. I'm just discussing what the point of it is there for. :)

      It's not security against people and getting secrets from the system. Lemme give you an example. Say someone who is writing an encryption module, doesn't want you messing with the initialization vector because it holds no value to other developers, then making it private is up to that developer. The users aren't always people on the other end of a program, but also people who develop using your API. Those people who write the API are the ones who define the architecture to be "upheld".

      I'm just pointing out that while yeah, it doesn't protect end users in the long run from getting data out of the system. Just make the process core dump, right? That protection is against people extending the system (or playing with it) in awkward ways that they shouldn't depend on. It might change, or may break something. That's what upholding the architecture is about. It means developers don't do stupid things and make it really hard for them to do just that and keeping the ideas behind the system right

      It's the bars around dangerous machinery. People aren't trusted to not hurting themselves. For perl, the bars are a simple line in the sand saying, don't cross this line. For some languages, it's a steel wall.


      Play that funky music white boy..
[reply]

        With my orginal post, I was thinking of the situation where you read a password from the user, check it in a database, and then get rid of it. Having it automatically self-destruct could be handy. Abigail pointed out that this is probably useful in far fewer situations than I thought it might be.

        Also, it could force you to rely on the implementation of certain functions. For instance, your password-checker sub's first implementation might only need to fetch the password once, but a later implementation fetches it twice. Now you have to increment your self-destruct paramameter in a place that might be very distant from the password checker sub.

        In any case, it was just a brainstorm. A thought placed Out There without any initial prejudice.

        ----
        : () { :|:& };:

        Note: All code is untested, unless otherwise stated

[reply]
[d/l]

In Section Meditations