----- Original message ----- >From MAILER-DAEMON@bouncehost Sent: Wed, 4 Jul 2012, 06:26:36 GMT-10 To [email protected] Subject failure notice
> Hi. This is the qmail-send program. > I'm afraid I wasn't able to deliver your message to the following addresses. > This is a permanent error; I've given up. Sorry it didn't work out. > > <[email protected]>: > 140.211.11.136 failed after I sent the message. > Remote host said: 552 spam score (5.1) exceeded threshold > (HTML_MESSAGE,MISSING_MIMEOLE,SPF_PASS,TRACKER_ID > > --- Below this line is a copy of the message. > > Return-Path: <[email protected]> > Received: (qmail 62942 invoked by uid 16710); 3 Jul 2012 20:26:06 -0000 > Received: from unknown (HELO [106.70.12.253]) ([106.70.12.253]) > (envelope-sender <[email protected]>) > by 207.57.65.70 (qmail-ldap-1.03) with SMTP > for <[email protected]>; 3 Jul 2012 20:26:06 -0000 > From: Peter Firmstone <[email protected]> > Reply-To: Peter Firmstone <[email protected]> > To: [email protected] > Subject: Re: Distributed network security > X-Mailer: Modest 3.1 > References: <1341318236.4211.6.camel@Nokia-N900-51-1> > In-Reply-To: <1341318236.4211.6.camel@Nokia-N900-51-1> > Content-Type: multipart/alternative; boundary="=-PcK9hqoxbVQI2x4oV9Bg" > X-MSMail-Priority: Normal > X-Priority: 3 > Date: Wed, 04 Jul 2012 06:26:02 +1000 > Message-Id: <1341347162.6337.8.camel@Nokia-N900-51-1> > Mime-Version: 1.0 > > > --=-PcK9hqoxbVQI2x4oV9Bg > Content-Type: text/plain; charset=utf-8 > Content-ID: <1341347161.6337.5.camel@Nokia-N900-51-1> > Content-Transfer-Encoding: 8bit > > ...Continued from previous discussion. > > LocalSubjectProtectionDomain > > What permissions should local users have? > > FilePermission(<<ALL FILES>>) > AWTPermission("*") > AudioPermission("*") > SocketPermission("*", "connect,accept,listen") > > The local user can rely on the OS and local process to control access to local > resources. > > A RemoteSubjectProtectionDomain should be given the same permissions as an > untrusted proxy (perhaps suitable for a remote guest user), other permissions > can be assigned per Principal assigned during login, based on Policy files. > > We can have roles for remote users, as Gregg has suggested. > > Meanwhile, untrusted code is of far less concern, if it tries denial of > service, > just close the app and start again, untrusted code can't get access to local > files, create threads, access the clipboard or screen. About all untrusted > code > can do is cause a stack overflow and crash the app, more sophisticated attacks > like timing attacks are difficult to prevent in any software, but the > difficulty > barrier is quite high for crackers. Deserialisation attacks can be mitigated > by > placing an untrusted domain on the stack prior to unmarshalling. If there's a > jvm class that performs a priviledged action that could compromise security, > we > don't have to grant it permission it doesn't need. > > I think this gets us to a place where it's viable to run untrusted dynamic > downloaded code. We must also remember that users often run downloaded > programs > from the net, with full user privileges. > > Cheers, > > Peter. > > > --=-PcK9hqoxbVQI2x4oV9Bg > Content-Type: text/html; charset=utf-8 > Content-ID: <1341347161.6337.7.camel@Nokia-N900-51-1> > Content-Transfer-Encoding: 7bit > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" > "http://www.w3.org/TR/html4/loose.dtd";> <html><head> > <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> > <meta name="generator" content="Osso Notes"> > <title></title></head> > <body> > <p>...Continued from previous discussion. > <br> > <br>LocalSubjectProtectionDomain > <br> > <br>What permissions should local users have? > <br> > <br>FilePermission(<<ALL FILES>>) > <br>AWTPermission("*") > <br>AudioPermission("*") > <br>SocketPermission("*", "connect,accept,listen") > <br> > <br>The local user can rely on the OS and local process to control access to > local resources. <br> > <br>A RemoteSubjectProtectionDomain should be given the same permissions as an > untrusted proxy (perhaps suitable for a remote guest user), other permissions > can be assigned per Principal assigned during login, based on Policy files. > <br> > <br>We can have roles for remote users, as Gregg has suggested. <br> > <br>Meanwhile, untrusted code is of far less concern, if it tries denial of > service, just close the app and start again, untrusted code can't get access > to > local files, create threads, access the clipboard or screen. About all > untrusted code can do is cause a stack overflow and crash the app, more > sophisticated attacks like timing attacks are difficult to prevent in any > software, but the difficulty barrier is quite high for crackers. >  Deserialisation attacks can be mitigated by placing an untrusted domain > on > the stack prior to unmarshalling.  If there's a jvm class that performs a > priviledged action that could compromise security, we don't have to grant it > permission it doesn't need. <br> <br>I think this gets us to a place where > it's > viable to run untrusted dynamic downloaded code.  We must also remember > that > users often run downloaded programs from the net, with full user privileges. > <br> <br>Cheers, <br> <br>Peter. <br><br></p> </body> </html> > > --=-PcK9hqoxbVQI2x4oV9Bg-- >
