Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #23474 > unrolled thread

> Sandboxed power == More secure???

Back to article view | Back to comp.lang.java.programmer

Contents

  > Sandboxed power == More secure??? Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-04-17 07:45 +0800
    Re: > Sandboxed power == More secure??? Arne Vajhøj <arne@vajhoej.dk> - 2013-04-16 22:12 -0400
      Re: > Sandboxed power == More secure??? Lew <lewbloch@gmail.com> - 2013-04-16 19:25 -0700
        Re: > Sandboxed power == More secure??? Arne Vajhøj <arne@vajhoej.dk> - 2013-04-16 22:30 -0400
      Re: > Sandboxed power == More secure??? markspace <markspace@nospam.nospam> - 2013-04-17 09:14 -0700
        Re: > Sandboxed power == More secure??? Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-04-17 13:09 -0400
          Re: > Sandboxed power == More secure??? markspace <markspace@nospam.nospam> - 2013-04-17 11:37 -0700
            Re: > Sandboxed power == More secure??? Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-04-17 15:49 -0400
              Re: > Sandboxed power == More secure??? Arne Vajhøj <arne@vajhoej.dk> - 2013-04-17 19:10 -0400
              Re: > Sandboxed power == More secure??? Arne Vajhøj <arne@vajhoej.dk> - 2013-04-17 19:13 -0400
                Re: > Sandboxed power == More secure??? Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-04-17 21:12 -0400
                  Re: > Sandboxed power == More secure??? Arne Vajhøj <arne@vajhoej.dk> - 2013-04-17 21:34 -0400
                  Re: > Sandboxed power == More secure??? Arne Vajhøj <arne@vajhoej.dk> - 2013-04-17 21:39 -0400
        Re: > Sandboxed power == More secure??? Arne Vajhøj <arne@vajhoej.dk> - 2013-04-17 19:06 -0400
          Re: > Sandboxed power == More secure??? Joerg Meier <joergmmeier@arcor.de> - 2013-04-18 03:04 +0200
    Re: > Sandboxed power == More secure??? Roedy Green <see_website@mindprod.com.invalid> - 2013-04-17 10:37 -0700
      Re: > Sandboxed power == More secure??? paul.cager@gmail.com - 2013-04-17 10:54 -0700
      Re: > Sandboxed power == More secure??? Arne Vajhøj <arne@vajhoej.dk> - 2013-04-17 19:02 -0400
        Re: > Sandboxed power == More secure??? Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-04-25 10:09 +0800
          Re: > Sandboxed power == More secure??? Arne Vajhøj <arne@vajhoej.dk> - 2013-04-24 22:30 -0400
          Re: > Sandboxed power == More secure??? markspace <markspace@nospam.nospam> - 2013-04-25 08:54 -0700
            Re: > Sandboxed power == More secure??? Arne Vajhøj <arne@vajhoej.dk> - 2013-04-26 22:11 -0400
              Re: > Sandboxed power == More secure??? markspace <markspace@nospam.nospam> - 2013-04-26 20:05 -0700
                Re: > Sandboxed power == More secure??? Arne Vajhøj <arne@vajhoej.dk> - 2013-04-27 22:23 -0400
                Re: > Sandboxed power == More secure??? "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-04-28 12:09 +0100
                  Re: > Sandboxed power == More secure??? Arne Vajhøj <arne@vajhoej.dk> - 2013-04-28 09:43 -0400

Page 2 of 2 — ← Prev page 1 [2]

#23648

On 4/24/2013 7:09 PM, Richard Maher wrote:
> I think it's madness but the docs at: -
> https://www.java.com/en/download/help/appsecuritydialogs.xml#background
>
> http://www.oracle.com/technetwork/java/javase/tech/java-code-signing-1915323.html

Thanks for posting these.  That second document has some links of its 
own, one of which is here:

<http://www.oracle.com/technetwork/java/seccodeguide-139067.html>

That if you ask me is a pretty stunning indictment of Java's broken 
security model.  The amount of work they push onto the developer, and 
the amount of security code that must be understood before writing any 
applet is pretty astounding.

Oracle should really devote some resources to fixing this.  And by 
"fixing" I mean obviating every last item in that document.

[toc] | [prev] | [next] | [standalone]

#23661

On 4/25/2013 11:54 AM, markspace wrote:
> On 4/24/2013 7:09 PM, Richard Maher wrote:
>> I think it's madness but the docs at: -
>> https://www.java.com/en/download/help/appsecuritydialogs.xml#background
>>
>> http://www.oracle.com/technetwork/java/javase/tech/java-code-signing-1915323.html
>>
>
> Thanks for posting these.  That second document has some links of its
> own, one of which is here:
>
> <http://www.oracle.com/technetwork/java/seccodeguide-139067.html>
>
> That if you ask me is a pretty stunning indictment of Java's broken
> security model.  The amount of work they push onto the developer, and
> the amount of security code that must be understood before writing any
> applet is pretty astounding.
>
> Oracle should really devote some resources to fixing this.  And by
> "fixing" I mean obviating every last item in that document.

I don't think that is possible or desirable.

A lot of this has to be done by the developer based
on context.

Arne

[toc] | [prev] | [next] | [standalone]

#23664

On 4/26/2013 7:11 PM, Arne Vajhøj wrote:

> On 4/25/2013 11:54 AM, markspace wrote:
>>
>> <http://www.oracle.com/technetwork/java/seccodeguide-139067.html>
>>...
>> Oracle should really devote some resources to fixing this.  And by
>> "fixing" I mean obviating every last item in that document.

>
> I don't think that is possible or desirable.
>
> A lot of this has to be done by the developer based
> on context.

I see a few things in that document that should be done by the 
developer.  I see a lot more that really shouldn't be the developers 
concern, under any circumstances.

I'd honestly like to see some discussion about it because I'd like to 
propose some fixes to Oracle.  Otherwise I think applets are just plain 
doomed.

For example, some "context" for applets that I'm concerned about where 
Oracle pushes security onto the developer:

1. Mutable statics.  This includes private fields, if I read the 
document aright.

2. "Exceptions."  WTH?

3. Call backs, including applets, which are apparently invoked with full 
permissions.

All of those are big areas of concern.  I honestly don't see what to do 
with the mutable statics.  You need globals in any non-trivial app.

Exceptions cause a security breach?  How the heck I'm I supposed to deal 
with that?

And applets are all callbacks, so apparently the Java plug-in can't even 
call my applet correctly at all.

Those are all issues, and they need to be addressed in a serious way. 
Or Oracle is simply not going to have any presence on the desktop in any 
way.  Which would be too bad, because imo there's a need for more 
platforms than just the vendor supplied (Windows, *nix) ones.

[toc] | [prev] | [next] | [standalone]

#23682

On 4/26/2013 11:05 PM, markspace wrote:
> On 4/26/2013 7:11 PM, Arne Vajhøj wrote:
>
>> On 4/25/2013 11:54 AM, markspace wrote:
>>>
>>> <http://www.oracle.com/technetwork/java/seccodeguide-139067.html>
>>> ...
>>> Oracle should really devote some resources to fixing this.  And by
>>> "fixing" I mean obviating every last item in that document.
>
>>
>> I don't think that is possible or desirable.
>>
>> A lot of this has to be done by the developer based
>> on context.
>
> I see a few things in that document that should be done by the
> developer.  I see a lot more that really shouldn't be the developers
> concern, under any circumstances.

* release resources
* protect against integer overflow
* no sensitive info in exceptions
* no sensitive info in logs
* protect against SQL injection
* protect against XSS
* limit visibility
* validate input
* no sensitive info serialized
* check access
etc.

are all very important items. And pretty close to OWASP.

But doing this is programming.

Java language/Java library/Java VM can do this for programmers.

> I'd honestly like to see some discussion about it because I'd like to
> propose some fixes to Oracle.  Otherwise I think applets are just plain
> doomed.
>
> For example, some "context" for applets that I'm concerned about where
> Oracle pushes security onto the developer:
>
> 1. Mutable statics.  This includes private fields, if I read the
> document aright.

They note that even if private then there is most likely a method
to change it with.

They are expressing concerns because JavaScript / other applets may
change state of an applet.

> 2. "Exceptions."  WTH?

What about exceptions?

The need to free resources and not reveal sensitive information
is valid for most Java not just applets.

> 3. Call backs, including applets, which are apparently invoked with full
> permissions.

Applets are not invoked with full permissions.

But the text is interesting:

<quote>
Guideline 9-2: Beware of callback methods

Callback methods are generally invoked from the system with full 
permissions. It seems reasonable to expect that malicious code needs to 
be on the stack in order to perform an operation, but that is not the 
case. Malicious code may set up objects that bridge the callback to a 
security checked operation. For instance, a file chooser dialog box that 
can manipulate the filesystem from user actions, may have events posted 
from malicious code. Alternatively, malicious code can disguise a file 
chooser as something benign while redirecting user events.

Callbacks are widespread in object-oriented systems. Examples include 
the following:

     Static initialization is often done with full privileges
     Application main method
     Applet/Midlet/Servlet lifecycle events
     Runnable.run
</quote>

I can't quite see what scenario they are talking about.

> Those are all issues, and they need to be addressed in a serious way. Or
> Oracle is simply not going to have any presence on the desktop in any
> way.

Applets are only one type of desktop app.

Normal Java apps run with full permission anyway.

And neither applets nor Java desktop apps are widely used.

Oracle does not make a cent from applets or Java desktop
apps, so they most likely do not care about usage.

I am assuming that Oracle's only interest in this is to preserve
Java's "good name". Because Oracle is selling billions of
dollars of server side Java stuff. And if everybody get the
impression that Java is "insecure", then it could hurt that
business.

Arne

[toc] | [prev] | [next] | [standalone]

#23693

markspace wrote:

> Exceptions cause a security breach?  How the heck I'm I supposed to deal
> with that?
>
> And applets are all callbacks, so apparently the Java plug-in can't even
> call my applet correctly at all.
>
> Those are all issues, and they need to be addressed in a serious way.
> Or Oracle is simply not going to have any presence on the desktop in any
> way.  Which would be too bad, because imo there's a need for more
> platforms than just the vendor supplied (Windows, *nix) ones.

I don't see anything much that's specific to desktop apps (let alone applets). 
Quoted:

These guidelines are of interest to all Java developers, whether they create 
trusted end-user applications and applets, implement the internals of a 
security component, or develop shared Java class libraries that perform common 
programming tasks. Any implementation bug can have serious security 
ramifications and could appear in any layer of the software stack.

The main thing that's wrong with it, to my mind, is that it's so bloody long!

And as a result I haven't bothered to read all of it (and don't intend to).  By 
my impression of it after a quick skim is that it's made up of four kinds of 
guidance:

Motherhood and apple pie stuff (Restrict privileges, Do not log highly 
sensitive information, Validate inputs,...) which would apply to pretty-much 
any code in any language on any platform (where security is any kind of concern 
at all).  We can't fault them on that, but it might be better split out into 
separate guidance ("What every would-be programmer should know before being 
allowed within twenty miles of a computer").

Stuff that basically can be paraphrased as "Yup, Sun designed the language 
wrong -- we'll all have to live with it.  Sorry...").  Integer overflows (not 
only do they happen but they happen silently!). Lack of a /convenient/ way of 
managing limited resources (such as C#s "using" syntax).  Lack of immutable 
references (though I have my doubts about whether that can be made meaningful 
/and/ useful).  Even /having/ public (or protected) mutable fields in the 
language at all.  Public constructors (rather than factory methods).  Etc...

A few examples of plain daft behaviour of the platform classes which should be 
fixed pronto.  (Such as allowing HTML in Swing components by default).  Just 
about everything to do with serialisation.

And the last category can be summed up as "the security model is too 
complicated, and very easy to get wrong".  That's the biggest (by linecount) 
item.  Not sure what to do about that.  Maybe a library along the lines of Doug 
Lea's concurrency stuff that hides all the fragile mess inside nice tight 
interfaces with clear simple guidelines ??  I say that, but I'm not going to 
claim that /I/ could design and implement such a beast (not without 
language/JVM changes anyway).

BTW:

> All of those are big areas of concern.  I honestly don't see what to do
> with the mutable statics.  You need globals in any non-trivial app.

I was under the impression that each applet ran in its own classloader.  Am I 
wrong ?  If not then mutable statics are no worse a problem in applets than 
they are anywhere else.

    -- chris 

[toc] | [prev] | [next] | [standalone]

#23697

On 4/28/2013 7:09 AM, Chris Uppal wrote:
> The main thing that's wrong with it, to my mind, is that it's so bloody long!
>
> And as a result I haven't bothered to read all of it (and don't intend to).  By
> my impression of it after a quick skim is that it's made up of four kinds of
> guidance:
>
> Motherhood and apple pie stuff (Restrict privileges, Do not log highly
> sensitive information, Validate inputs,...) which would apply to pretty-much
> any code in any language on any platform (where security is any kind of concern
> at all).  We can't fault them on that, but it might be better split out into
> separate guidance ("What every would-be programmer should know before being
> allowed within twenty miles of a computer").

Yep.

> Stuff that basically can be paraphrased as "Yup, Sun designed the language
> wrong -- we'll all have to live with it.  Sorry...").  Integer overflows (not
> only do they happen but they happen silently!). Lack of a /convenient/ way of
> managing limited resources (such as C#s "using" syntax).  Lack of immutable
> references (though I have my doubts about whether that can be made meaningful
> /and/ useful).  Even /having/ public (or protected) mutable fields in the
> language at all.  Public constructors (rather than factory methods).  Etc...

C# using was added in Java 7.

> A few examples of plain daft behaviour of the platform classes which should be
> fixed pronto.  (Such as allowing HTML in Swing components by default).  Just
> about everything to do with serialisation.
>
> And the last category can be summed up as "the security model is too
> complicated, and very easy to get wrong".  That's the biggest (by linecount)
> item.  Not sure what to do about that.  Maybe a library along the lines of Doug
> Lea's concurrency stuff that hides all the fragile mess inside nice tight
> interfaces with clear simple guidelines ??  I say that, but I'm not going to
> claim that /I/ could design and implement such a beast (not without
> language/JVM changes anyway).

Libraries that are powerful, flexible, simple, secure
and good performing are not easy to write.

> I was under the impression that each applet ran in its own classloader.  Am I
> wrong ?  If not then mutable statics are no worse a problem in applets than
> they are anywhere else.

I think the concern is that something internal can alter the state and
thereby alter the execution of the applet.

JavaScript can access fields and call methods in an applet.

Arne

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web