in reply to Re^3: Attack on Perl or Perl's need better PR (again)
in thread Attack on Perl or Perl's need better PR (again)

dragonchild is doing an excellent job, certainly more cogently than I will be able to do. (Thank, you dragonchild).

There is a lot more to security than a language's (say) memory access model or potential race conditions. Many very serious examples of security problems have absolutely nothing to do with software: trusted users doing improper actions which are, nonetheless, well within their security profiles (sysadmins may have legitimate need to get into the bank's account database), careless disposal or loss of hardware with confidential information, users putting their impossible-to-memorize passwords on PostIt™s stuck on their monitors, et al.

Restricting my comments to software: There is no way language selection can prevent something like

&transfer_all_money_from(cat => \$user) if($user eq 'theMice' and &is_
+away('cat'));

[download]

I don't see how E, CaPerl, etc could prevent this.

emc

Netlib

Replies are listed 'Best First'.
Re^5: Attack on Perl or Perl's need better PR (again)
by Anonymous Monk on Dec 01, 2005 at 01:03 UTC
    There is no way language selection can prevent something like 
    &transfer_all_money_from(cat => \$user) if($user eq 
'theMice' and &is_away('cat'));

    [download]
    Capability-based Financial Instruments
    Abstract: Every novel cooperative arrangement of mutually suspicious parties interacting electronically --- every smart contract --- effectively requires a new cryptographic protocol. However, if every new contract requires new cryptographic protocol design, our dreams of cryptographically enabled electronic commerce would be unreachable. Cryptographic protocol design is too hard and expensive, given our unlimited need for new contracts.
    If you don't want to read the papers, check out the video.
[reply]
[d/l]

      I repeat: there is no way a language can prevent illicit activity if it is within the user's security profile, especially if the user has access to the source code and authority to change it: DBA's need to be able to read and write databases, sysadmins need to be able to read and write user account information.

      And what is the implementation language behind E, CaPerl, etc? I would bet a fair amount of money it's C; is hiding C's vulnerabilities behind a "secure" language front-end really secure? Or is it just papering over a problem?

      emc

      Netlib
[reply]
        I repeat: there is no way a language can prevent illicit activity if it is within the user's security profile
        Well, that's the whole point behind a language based security model like in E. A program doesn't run with the security profile of the user which invokes it. In fact it has the least amount of privledge necessary. There is even a name for it, the Principle of Least Authority. Here's another paper worth reading. The Structure of Authority: Why security is not a separable concern
        Common programming practice grants excess authority for the sake of functionality; programming principles require least authority for the sake of security. If we practice our principles, we could have both security and functionality. Treating security as a separate concern has not succeeded in bridging the gap between principle and practice, because it operates without knowledge of what constitutes least authority. Only when requests are made -- whether by humans acting through a user interface, or by one object invoking another -- can we determine how much authority is adequate. Without this knowledge, we must provide programs with enough authority to do anything they might be requested to do.
        ...
        And what is the implementation language behind E, CaPerl, etc?
        There's currently a version of E written in Java. CaPerl compiles down to Perl (which is of course interpreted by a program written in C).
        is hiding C's vulnerabilities behind a "secure" language front-end really secure?
        Yes.
        Or is it just papering over a problem?
        No. Think of buffer overflows again. Is the problem more prevalent in C or Perl (and remember perl is written in C). Are you arguing that Perl is the most secure language ever written and any attempts to improve on it are futile? Maybe I'm getting off track. I thought this discussion started with security vuneralibilities in Webmin? This is similiar to the attack senario for the Darpa Browser described here and here. Note that unlike Webmin, the attack are successfully thwarted.
[reply]
Re^5: Attack on Perl or Perl's need better PR (again)
by Anonymous Monk on Nov 30, 2005 at 23:40 UTC
    Many very serious examples of security problems have absolutely nothing to do with software
    Just because you can't fix all problems, does that mean we should try to fix any? You can also say seatbelts in cars are potentially dangerous. The buckle could fail to latch, causing a false sense of security. You could potentially strangle someone with the belt. Also, in some instances, the buckle might jam, causing the passenger to be trapped in a burning vehicle.
    I don't see how E, CaPerl, etc could prevent this.
    That's why links were provided, so you could study up! If nothing else, the next time this topic comes up, you'll be in a position to say "I've read some of the revalent literature and I don't agree, because...". That's a much stronger position to argue from instead of professing a failure of imagination.
[reply]

In Section Meditations