Re^6: Attack on Perl or Perl's need better PR (again)

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

Comment on Re^6: Attack on Perl or Perl's need better PR (again)

Replies are listed 'Best First'.
Re^7: Attack on Perl -or- Perl needs better PR (again) by Anonymous Monk on Dec 01, 2005 at 16:27 UTC
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^8: Attack on Perl -or- Perl needs better PR (again) by demerphq (Chancellor) on Dec 01, 2005 at 18:08 UTC
Not that I think its directly relevent, but recently I've been writing some code on Win32 that works with secure registry keys. I discovered something there that to me offers an insight into why Win32 has so many security issues. Its damn hard to do stuff in Win32 securely. Getting a security token setup with the right privs etc is a lot of work. But you dont need to bother, because everything is set up so that if dont do the security malarky the OS defaults to "access/everyone". If Win32 used "access/owner" as the default, and forced people to do work to make it "access/everyone" then things would be a lot more secure. The lesson ive learned from this is that if a security model is painful to work with and easy to ignore the end result is that nobody will bother. --- $world=~s/war/peace/g	[reply]