You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter Firmstone <pe...@zeus.net.au> on 2012/07/03 23:58:31 UTC
Fw: failure notice
----- Original message -----
>From MAILER-DAEMON@bouncehost
Sent: Wed, 4 Jul 2012, 06:26:36 GMT-10
To peter.firmstone@zeus.net.au
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.
>
> <de...@river.apache.org>:
> 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: <pe...@zeus.net.au>
> 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 <pe...@zeus.net.au>)
> by 207.57.65.70 (qmail-ldap-1.03) with SMTP
> for <de...@river.apache.org>; 3 Jul 2012 20:26:06 -0000
> From: Peter Firmstone <pe...@zeus.net.au>
> Reply-To: Peter Firmstone <pe...@zeus.net.au>
> To: dev@river.apache.org
> Subject: Re: Distributed network security
> X-Mailer: Modest 3.1
> References: <13...@Nokia-N900-51-1>
> In-Reply-To: <13...@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: <13...@Nokia-N900-51-1>
> Mime-Version: 1.0
>
>
> --=-PcK9hqoxbVQI2x4oV9Bg
> Content-Type: text/plain; charset=utf-8
> Content-ID: <13...@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: <13...@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--
>