Sean Godsell | 7 Feb 05:57 2008
Picon

Javasss (Safe secure sandbox)


Hello again openjdk people,

I have added a number of new features and cleaned up some of the functions that were added previously. 
Javasss enhances the openjdk in a number of areas.  The following is a list of enhancements:
    - Overwrite and lock users file paths to a specific base path
    - All temporary files can automatically be created in the base path without any program change to existing applications
    - You can limit the amount of storage being used in a path or file 
    - You can limit the # of file and directories being created in path
    - You can make any path read only or read/write
    - You can allow or deny whether libraries can be loaded from a path.
    - You can allow or deny whether native methods can be used from a path.
    - You can have multiple paths to allow users to read or write to with different
       limiting storage and or # or files and directories.
    - You can limit the number of threads and thread priority.
    - You can limit the maximum # of windows being created.
    - You can allow or deny hosts and ports being used.
    - You can allow or deny execution of runtime process.
    - You can limit the amount of socket traffic throughput in bytes per second
    - All items can be controlled in a simple properties file
    - Allow threads to have different paths, and/or lock every new thread with certain paths
    - Allow users to configure thread paths using a key.
    - Existing programs and applications can run without any changes or modifications.

A security manager cannot even do half the items previously listed.  There is complete source code and
examples at the following site:

    http://sourceforge.net/projects/javasss/

Sean Godsell
(Continue reading)

Sean Godsell | 12 Feb 22:50 2008
Picon

Javasss (Safe secure sandbox) for jdk 6 and openjdk 7


 Hello once again openjdk people,

Previously Javass required openjdk 7.  Now it supports jdk 6 update 3.  The following is a list of enhancements:
     - Overwrite and lock users file paths to a specific base path (like chroot in unix)
     - All temporary files can automatically be created in the base path without any program change to existing applications
     - You can limit the amount of storage being used in a path or file 
     - You can limit the # of file and directories being created in path
     - You can make any path read only or read/write
     - You can allow or deny whether libraries can be loaded from a path.
     - You can allow or deny whether native methods can be used from a path.
     - You can have multiple paths to allow users to read or write to with different
        limiting storage and or # or files and directories.
     - You can limit the number of threads and thread priority.
     - You can limit the maximum # of windows being created.
     - You can allow or deny hosts and ports being used.
     - You can allow or deny execution of runtime process.
     - You can limit the amount of socket traffic throughput in bytes per second
     - All items can be controlled in a simple properties file
     - Allow threads to have different paths, and/or lock every new thread with certain paths
     - Allow users to configure thread paths using a key.
     - Existing programs and applications can run without any changes or modifications.

A security manager cannot even do half the items previously listed.  There is complete source code and
examples are at the following site:

    http://javasss.sourceforge.net/

Sean Godsell

(Continue reading)

Andreas Plesner Jacobsen | 18 Feb 10:28 2008
Picon

Caching behaviour of InetAddress

I've recently been introduced to the caching behaviour of InetAddress, 
and I think it may be improved.

The javadoc reads:
The InetAddress class has a cache to store successful as well as 
unsuccessful host name resolutions. The positive caching is there to 
guard against DNS spoofing attacks; while the negative caching is used 
to improve performance.

And that is all fine and well, but for multihomed hosts, I believe the 
current behaviour is

1) Not documented properly
2) Not correct

Coming from a unix-world, I'm used to the resolver handing out 
RR-replies in random order, and thus I would expect InetAddress to do 
the same, but a short test (courtesy of Arne Vajhøj) shows that 
InetAddress.getByName() will return the same IP for a lookup when the 
lookup is performed within the 10-second range of the cache:

public class DNSLookup { 

      private static final String MS = "www.microsoft.com"; 

      public static void main(String[] args) throws Exception { 

          Map<String, Integer> m = new HashMap<String, Integer>(); 

          InetAddress[] all = InetAddress.getAllByName(MS); 
(Continue reading)

Alan Bateman | 18 Feb 11:17 2008
Picon

Re: Caching behaviour of InetAddress

Andreas Plesner Jacobsen wrote:
> I've recently been introduced to the caching behaviour of InetAddress, 
> and I think it may be improved.
>
> The javadoc reads:
> The InetAddress class has a cache to store successful as well as 
> unsuccessful host name resolutions. The positive caching is there to 
> guard against DNS spoofing attacks; while the negative caching is used 
> to improve performance.
>
> And that is all fine and well, but for multihomed hosts, I believe the 
> current behaviour is
>
> 1) Not documented properly
> 2) Not correct
>
> Coming from a unix-world, I'm used to the resolver handing out 
> RR-replies in random order, and thus I would expect InetAddress to do 
> the same, 
The specification could be improved but changing InetAddress.getByName 
to return a random address is a significant change that could break 
existing applications. It might be better to define a new method, 
perhaps "getAnyByName", that randomly chooses one of the cached 
addresses for the host (or does a lookup if not in the cache). That 
would be a convenience to applications to avoid needing to invoke 
getAllByName and choose an address themselves.

-Alan.

(Continue reading)

Andreas Plesner Jacobsen | 18 Feb 12:43 2008
Picon

Re: Caching behaviour of InetAddress

Alan Bateman wrote:

Alan,

> The specification could be improved but changing InetAddress.getByName 
> to return a random address is a significant change that could break 
> existing applications. It might be better to define a new method, 
> perhaps "getAnyByName", that randomly chooses one of the cached 
> addresses for the host (or does a lookup if not in the cache). That 
> would be a convenience to applications to avoid needing to invoke 
> getAllByName and choose an address themselves.

I don't think it's a significant change, since that's how getByName() 
acts when the cache entries time out, so changing it would make it act a 
lot more consistently.

Actually, I think it's worth debating whether or not InetAddress should 
cache lookups at all, I think it's more fitting to delegate that to the 
underlying OS.

--

-- 
Andreas

Alan Bateman | 18 Feb 13:49 2008
Picon

Re: Caching behaviour of InetAddress

Andreas Plesner Jacobsen wrote:
> :
> I don't think it's a significant change, since that's how getByName() 
> acts when the cache entries time out, so changing it would make it act 
> a lot more consistently.
>
> Actually, I think it's worth debating whether or not InetAddress 
> should cache lookups at all, I think it's more fitting to delegate 
> that to the underlying OS.
>
Search for a ~1996 paper on DNS spoofing attacks from Princeton 
University as that gives useful background on this topic and is the 
original reason for the caching. When a security manager is set then it 
caches forever and getByName will always return the same address. There 
was some capitulation on this topic in jdk6 so that it doesn't cache 
forever when there isn't a security manager. There was analysis done at 
the time on the implications of the change but I don't know if that 
included changing the behavior of the getByName method (Michael?).

-Alan.

Andreas Plesner Jacobsen | 18 Feb 14:16 2008
Picon

Re: Caching behaviour of InetAddress

Alan Bateman wrote:

Alan,

>> I don't think it's a significant change, since that's how getByName() 
>> acts when the cache entries time out, so changing it would make it act 
>> a lot more consistently.
>>
>> Actually, I think it's worth debating whether or not InetAddress 
>> should cache lookups at all, I think it's more fitting to delegate 
>> that to the underlying OS.
>>
> Search for a ~1996 paper on DNS spoofing attacks from Princeton 
> University as that gives useful background on this topic and is the 
> original reason for the caching. When a security manager is set then it 
> caches forever and getByName will always return the same address. There 
> was some capitulation on this topic in jdk6 so that it doesn't cache 
> forever when there isn't a security manager. There was analysis done at 
> the time on the implications of the change but I don't know if that 
> included changing the behavior of the getByName method (Michael?).

Thanks for the background info. Incidentally, that brings us to a third 
inconsistent operating mode of getByName(), so we're up to three 
different behaviours:

1. When running under a security manager, we cache forever
2. When not running under a security manager, with more than ten seconds 
between name lookups, we return random answers (at least if the dns 
reply is delivered randomized to java)
3. When not running under a security manager, with less than ten seconds 
(Continue reading)

John Pritchard | 18 Feb 18:39 2008

Re: Caching behaviour of InetAddress


a) The java.net cache is replicating the NSCD (OS caching), which are the appropriate layer for this kind of caching. 

b) If a security policy requires a kind of caching, then the replaceable and extensible security manager architecture should be used for this.


On 2/18/08, Andreas Plesner Jacobsen <apj.lists-VhrhkM4H5Pg@public.gmane.org> wrote:

Actually, I think it's worth debating whether or not InetAddress should
cache lookups at all, I think it's more fitting to delegate that to the
underlying OS.

Florian Weimer | 18 Feb 18:56 2008
Picon

Re: Caching behaviour of InetAddress

* Alan Bateman:

> Search for a ~1996 paper on DNS spoofing attacks from Princeton
> University as that gives useful background on this topic and is the
> original reason for the caching.

That paper is probably out of date by now.  Interaction of expiry and
poisoning hasn't been fully understood back then.

> When a security manager is set then it caches forever and getByName
> will always return the same address.

This is probably related to DNS pinning/anti-pinning attacks, not to
cache poisoning.

Alan Bateman | 18 Feb 22:37 2008
Picon

Re: Caching behaviour of InetAddress

Andreas Plesner Jacobsen wrote:
> :
> Thanks for the background info. Incidentally, that brings us to a 
> third inconsistent operating mode of getByName(), so we're up to three 
> different behaviours:
>
> 1. When running under a security manager, we cache forever
> 2. When not running under a security manager, with more than ten 
> seconds between name lookups, we return random answers (at least if 
> the dns reply is delivered randomized to java)
> 3. When not running under a security manager, with less than ten 
> seconds between name lookups, we return the same answer on every query.
That is basically it as per jdk6 (caching was always forever in releases 
prior to jdk6). The spec doesn't require a particular caching period and 
in the Sun implementation it is 30 seconds (and 10 seconds for 
unsuccessful lookups). You can of course configure the caching period or 
disable it completely by means of security properties.

>
> As far as I can see from what I've been able to google, the problem 
> lies in that applets may be cheated in connecting to a different host, 
> and that this makes it easier (actually invisible) to the applet 
> author that there may be more than one record in the dns reply.
>
> I may not have a lot of say in this, but I still don't feel this is 
> the right solution. Do you perhaps have some more resources to any 
> previous discussion on the subject?
I don't think this issue has been discussed on this mailing list but if 
you google for DNS pinning you should find a lot on this topic. Many 
other technologies and products (browsers, plug-ins, ...) also pin.

-Alan.


Gmane