RE: [SC-L] Opinion re an interesting article on Linux security in Linux Journal

[Nick Lothian]

> 
> > To secure a machine from malware introduced by a naive user it is
> > required that naive users not have the privilege to introduce
> > software that can be executed by them or by other naive users.
> 
> I would disagree.  There's nothing wrong with allowing naïve users to
> introduce software they or others can execute - provided its execution
> is appropriately sandboxed.
> 
> Trouble is, _that_ is hard.  Java in web-browsers tried it, 
> and gave us
> bugs in the jvm sandbox.  Also, what the sandboxes should permit the
> sandboxed software to do varies from site to site, and in some cases
> from machine to machine, and some of those sites don't have anyone
> competent to figure out what the restrictions should be for them, much
> less correctly configure the sandbox to implement them.
> 

I'd go futher - I think it is extremley rare that anyone configures their
sandbox properly. I "do" Java development, and I would guess that less than
10% of application server deployments are done with the Java security
manager enabled.

I'm not aware of any statistics in this area (Java deployments using the
sandbox vs not using it), and I'd be very interested any any hard numbers.

Nick

RE: [SC-L] Dot Net guidelines?

[Nick Lothian]

> 
> Hi All,
> my boss has asked me to see if there are any guidelines out 
> there regarding 
> dot Net...
> 
> We currently use Java, but we expect the development teams to 
> want to use 
> microsoft's lastest toy sooner or later..
> 
> Thanks,
> 
> Bret
> 


 is a good place to start.

RE: [SC-L] Programming languages used for security

[Nick Lothian]

> 
> Does anyone have pointers to articles on designing API's so 
> that they are
> easy to use securely?
> 

Not specifically related to security, but
http://www.cafeconleche.org/XOM/designprinciples.xhtml#d0e161 is one of the
better things I've seen about designing APIs.

Nick

RE: [SC-L] Programming languages -- the "third rail" of secure coding

[Nick Lothian]

> I'd also point out that if it's languages you're trying to list,
> JavaScript arguably should not have a separate entry from Java 

Yes it should - they are substantially different languages, even if we look
at them only syntactically. You could argue that Javascript should be listed
as ECMAScript, though. There are a bigger problems with that list than this,
though.

Nick

RE: [SC-L] Programming languages -- the "third rail" of secure

[Nick Lothian]

> >IMHO, though, any such effort is pointless.  The reality is 
> that we're going
> >to be stuck with C/C++, Java, C#, FORTRAN, COBOL, and various
> >interpreted/scripting languages for a very long time.  
> Rather than argue
> >about what makes something good/better, we'd be better off 
> figuring out how
> >to use them more effectively.
> 
> The problem is that some people persist in using less-safe 
> languages for
> new code.  When put into a discussion (here) with those who 
> say "Use the
> best tool", a non-conversation takes place.
> 
> If the list were retitled to be "Secure Coding in 
> Unsupportive Languages"
> or "Secure Coding with Approprate Languages" then half of us 
> would leave
> and the rest could actually conduct a discussion.
> -- 
> Larry Kilgallen
> 

What are peoples opinions of the languages listed above?

Would I be overly controversial in saying:

C/C++: Unsafe (for most people)
Java/C#: Reasonably safe (both provide protection against buffer overflows,
are type safe and provide built-in security mechanisms)
FORTRAN/COBOL: Don't know - my impression is that COBOL is fairly safe
Scripting Languages: Depends on the language. Lack of type safety can be a
problem, but on the other hand they are usually safe from buffer overflows
and the fact they you can do a lot more in fewer lines of code can make the
code safer by making errors more obvious.

Are there other languages in widespread use (ie, the language must be used
more than - say - Python) that are safer than those listed above? 

Nick

RE: [SC-L] Programming languages -- the "third rail" of secure coding

[Nick Lothian]

> >Java/C#: Reasonably safe (both provide protection against 
> buffer overflows,
> >are type safe and provide built-in security mechanisms)
> >FORTRAN/COBOL: Don't know - my impression is that COBOL is 
> fairly safe
> >Scripting Languages: Depends on the language. Lack of type 
> safety can be a
> >problem, but on the other hand they are usually safe from 
> buffer overflows
> >and the fact they you can do a lot more in fewer lines of 
> code can make the
> >code safer by making errors more obvious.
> >
> >Are there other languages in widespread use (ie, the 
> language must be used
> >more than - say - Python) that are safer than those listed above? 
> 
> Certainly Ada is a lot safer than those above, and the SPARK subset
> we have discussed here is even safer (not just by being a subset but
> also by supporting proofs of correctness).  SPARK is much less widely
> deployed that whatever was used to implement Internet Explorer, but I
> have strong preference as to which of the two I would want used in the
> programming of fly-by-wire for an airplane on which I fly.
> -- 
> Larry Kilgallen
> 

What features make Ada safer than Java/C#? (I only have limited experience
with Ada but from memory there was nothing that jumps out at me as something
that Java lacks)

Nick