performed first, followed by unicast discovery
(multiple providers for each).
Security was a contraversial topic in the past, which has unfortunately
resulted in neglect of River's secure discovery protocols, we have
support nowadays to address security issues.
Security issues we'r
Hello,
I was not able to find out much information about the security of the service
discovery process in the apache river project.
Did I miss them and can you provide me links for them?
More Information and the background:
I study the security of service discovery protocols and right now I
my Samsung device.
Include original message
Original message
From: Patricia Shanahan
Sent: 08/04/2016 11:15:44 pm
To: dev@river.apache.org
Subject: Re: [DISCUSS] [vote] should we fix security flaws?
I am curious not so much about why a vote as about why a vote at this
particular time
you're right no need for this to happen now, consider it postponed.
Sent from my Samsung device.
Include original message
Original message
From: Patricia Shanahan
Sent: 08/04/2016 11:15:44 pm
To: dev@river.apache.org
Subject: Re: [DISCUSS] [vote] should we fix security flaws?
wherever
possible. That should include everyone listening to your security
concerns, and considering them in the light of actual use-cases for River.
Even though you have time available now that cannot be applied to River
3.0, I am not at all sure that is true for everyone. I attributed the
lack
To provide some context on why I've put this to a vote:
Previous arguments against fixing security have suggested it's not relevant to
local networks where River is deployed.
But I've received some mixed messages regarding security recently.
Although we can never fully gua
I don't think we should delay the release to fix security.
You have your reasons for not voting and I respect that.
Fixing security isn't technically difficult and I have fixes available, I'm
hoping for collaborative development, so they receive peer review /
modificat
I am not prepared to vote on this.
First of all, I would need, on a private list where we can go into
details of security issues, to get a feeling for the seriousness of the
flaws in question. A denial of service is, in many contexts, less
serious than file corruption.
We may want to
How do people on this project feel about security flaws?
Should we be fixing them?
I can provide evidence of vulnerabilities, I'm not proposing my fixes be
adopted.
Vote:
+1 Yes we should aim to fix security flaws.
0 don't care.
-1 No.
Regards,
Peter.
Sent from my Samsung device.
I support to have thoughtful discussion regarding River future direction
proposed by Patricia.
Bishnu Prasad Gautam
> Subject: Re: VOTE: Take Security seriously or my resignation.
> To: dev@river.apache.org
> From: p...@acm.org
> Date: Wed, 6 Jan 2016 07:13:23 -0800
>
> Ple
Thanks!
On 1/6/2016 12:54 PM, Peter wrote:
Vote withdrawn.
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Patricia Shanahan
Sent: 07/01/2016 01:13:23 am
To: dev@river.apache.org
Subject: Re: VOTE: Take Security seriously or my resignation
Vote withdrawn.
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Patricia Shanahan
Sent: 07/01/2016 01:13:23 am
To: dev@river.apache.org
Subject: Re: VOTE: Take Security seriously or my resignation.
Please, please cancel this.
We do need to
Peter,
I think that there might be a consensus for publishing 3.0 and then
considering security patches against it.
Bryan
Bryan Thompson
Chief Scientist & Founder
SYSTAP, LLC
4501 Tower Road
Greensboro, NC 27410
br...@systap.com
http://blazegraph.com
http://blog.blazegraph.com
Blazegr
3.0 first, then
>> discussion and study, then vote on future direction. I am sorely tempted
>> to resign if this premature vote goes ahead, regardless of the outcome,
>> but will not because I don't think such threats are an appropriate way
>> of influencing PMC votes.
Peter Firmstone wrote:
Option 1. I propose that we take security seriously, no security patches are to
be rejected prior to review, that we review and analyse them properly based on
merit. That discussions about security issues be taken seriously.
Option 2. Alternatively I resign my River comm
direction. I am sorely tempted
to resign if this premature vote goes ahead, regardless of the outcome,
but will not because I don't think such threats are an appropriate way
of influencing PMC votes.
Patricia
On 1/6/2016 4:21 AM, Peter Firmstone wrote:
Option 1. I propose that we take sec
Option 1. I propose that we take security seriously, no security patches are
to be rejected prior to review, that we review and analyse them properly based
on merit. That discussions about security issues be taken seriously.
Option 2. Alternatively I resign my River committer status
Please
Nice, Peter. Thanks for sharing.
Happy Holidays for all!
Zsolt
On Tue, Dec 22, 2015 at 5:49 AM, Peter Firmstone <
peter.firmst...@zeus.net.au> wrote:
> http://www.hindawi.com/journals/ijdsn/2015/205793/
>
> Regards,
>
> Peter
http://www.hindawi.com/journals/ijdsn/2015/205793/
Regards,
Peter
at, I don’t consider DOS a threat. I think it
> > > > > would make sense to be able to put a byte limit on the stream
> > > > > used to load the class, and possibly a time limit, but beyond
> > > > > that, I think you’re adding complexity that isn’t n
gt;>>> limit, but beyond that, I think you’re adding complexity that isn’t
>>>> needed. If you want to put a service on the web, use RESTful
>>>> services, not Jini. I’m sure there’s a discoverability tool out
>>>> there, if needed, but typically it isn’t.
>>>>
>>>> Also, since object serialization is not specific to River, I wonder
>>>> if there’s a better forum for these kinds of deep discussions. I
>>>> think it makes River look far harder than it is.
>>>>
>>>> Cheers,
>>>>
>>>> Greg Trasuk.
>>>>
>>>> On Feb 19, 2015, at 9:03 AM, Peter wrote:
>>>>
>>>>> What are your thoughts on security?
>>>>>
>>>>> Is it important to you? Is it important for River?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Peter.
>>>>
>>
>
I’m sure there’s a discoverability tool out
> > > there, if needed, but typically it isn’t.
> > >
> > > Also, since object serialization is not specific to River, I wonder
> > > if there’s a better forum for these kinds of deep discussions. I
> > > think it makes River look far harder than it is.
> > >
> > > Cheers,
> > >
> > > Greg Trasuk.
> > >
> > > On Feb 19, 2015, at 9:03 AM, Peter wrote:
> > >
> > > > What are your thoughts on security?
> > > >
> > > > Is it important to you? Is it important for River?
> > > >
> > > > Regards,
> > > >
> > > > Peter.
> > >
>
ain representing the
subject of the remote caller. Remote method invocation does so, only for
parameter arguments. In any case ObjectInputStream is an easy target for dos,
with or without downloaded code.
I've decided not to investigate Serialization security any further, at least
for the
BTW - I'm really interested in the reasoning why deserialization code
does not call the non-serializable superclass constructor in the
security context of the subclass(es) - so that it really mimics the
normal constructor call chain.
Michal
Michał Kłeczek (XPro) wrote:
> Isn't the i
Isn't the issue with non-serializable superclass constructor call this
one? :
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5353
If so - I don't really see how it relates to River - to be able to
expoit this kind of vulnerability an attacker must have already
downloaded and run his code -
better forum for these kinds of deep discussions. I
>> think it makes River look far harder than it is.
>>
>> Cheers,
>>
>> Greg Trasuk.
>>
>> On Feb 19, 2015, at 9:03 AM, Peter wrote:
>>
>>> What are your thoughts on security?
>>>
>>> Is it important to you? Is it important for River?
>>>
>>> Regards,
>>>
>>> Peter.
>>
deep discussions. I
think it makes River look far harder than it is.
Cheers,
Greg Trasuk.
On Feb 19, 2015, at 9:03 AM, Peter wrote:
What are your thoughts on security?
Is it important to you? Is it important for River?
Regards,
Peter.
isn’t.
Also, since object serialization is not specific to River, I wonder if there’s
a better forum for these kinds of deep discussions. I think it makes River
look far harder than it is.
Cheers,
Greg Trasuk.
On Feb 19, 2015, at 9:03 AM, Peter wrote:
> What are your thoughts on secur
What are your thoughts on security?
Is it important to you? Is it important for River?
Regards,
Peter.
Continuing on ...
Lets say for example, we have a secure OS and we provide a service on a
public port and we have a determined attacker attempting to use
deserialization to take over our system or bring it to its knees with
denial of service.
We know this is relatively easy with standard Obj
Ok, so here's where I discuss the how I've addressed serialization's
security issues:
From the source code:
// These two settings are to prevent DOS attacks.
private static final int MAX_ARRAY_LEN = 32768;
private static final int MAX_OBJECT_CACHE = 65664;
Th
ks unrelated to java.
I've been investigating Serialization security, identifying issues and
considering how to deal with them. I think everyone is aware
Serialization has security pitfalls, if I fail to mention an issue
you're aware of, please let me know.
At first I thought it was
ks unrelated to java.
I've been investigating Serialization security, identifying issues and
considering how to deal with them. I think everyone is aware
Serialization has security pitfalls, if I fail to mention an issue
you're aware of, please let me know.
At first I thought it was
Very interesting. Looking forward to the next episode.
> On Feb 4, 2015, at 9:11 AM, dev-digest-h...@river.apache.org wrote:
>
> to be continued...
There's a free certificate authority coming this year, I think privacy
and security are hot topics these days: https://letsencrypt.org/
Just a quick note about something I'm currently exploring.
The good thing about River is it allows you to be mostly ignorant of
security when
See
<https://builds.apache.org/job/River-QA-matrix/./jdk=JDK%201.7%20(latest),label=Ubuntu,test=com-sun-jini-test-spec-security-proxytrust-proxytrustverifier-IsTrustedObject_SecurityExceptionTest.td/20/>
--
Started by upstream project "Rive
On Jul 22, 2012, at 5:04 AM, Peter Firmstone wrote:
> Since Gregg hasn't utilised traditional jvm style Permissions for Principals,
> there is no possibility of elevating privileges when calling Subject.doAs, so
> granting "doAs" to untrusted code doesn't
custom
DomainCombiner that extends SubjectDomainCombiner.
Would this be an acceptable compromise?
In future, we can look at other tools to assist with simplifying security, such
as static bytecode analysis or FindBugs perhaps.
When I am using remote code, I either trust it by source, or
No, sorry, I was right the first time it definitely is a security problem, the
alternate method proposed still has too many pitfalls for the unwary,
developers are likely to make mistakes due to complexity, security needs to be
simpler. The current methods are brittle when used in a remote
Peter Firmstone wrote:
3. In Jini security documentation I've seen on the web,
Subject.doAsPrivileged is called with a null AccessControlContext
executing the proxy, in doing so the proxy PD is no longer on the
stack, however it isn't clear when the proxy ProtectionD
7;s not URL, a small change of semantics for a big
performance gain.
Another benefit of signed code is it protects local package private
security boundaries, of course this will create more errors if you
haven't got your preferred lists right.
So we could provide two additional methods in
a custom
> DomainCombiner that extends SubjectDomainCombiner.
>
> Would this be an acceptable compromise?
>
> In future, we can look at other tools to assist with simplifying security,
> such as static bytecode analysis or FindBugs perhaps.
When I am using remote code, I either trust it b
Permission to that which the Subject has in common with other
code on the stack, but it cannot be used by code to gain privilege if it
uses a custom DomainCombiner that extends SubjectDomainCombiner.
Would this be an acceptable compromise?
In future, we can look at other tools to assist with sim
erver),
without granting smart proxy code my local Principal Permissions from my
local domain. I want to allow Subjects to cross authority domains
(personal, company and country network boundaries), where trust relations
aren't implicit."
"Penny for your thoughts?"
>From exper
are made available on the internet.
One solution might be to add methods similar to Subject's static methods
to net.jini.security.Security.
As I mentioned earlier (see Re: Distributed Network Security), we could
extend and modify SubjectDomainCombiner to add a SubjectProtectionDomain
to the c
Maybe this time?
What about when a client communicates with a remote server?
For example, a remote policy service, where an admin has decided to update all
nodes with new policy and a process executes that running under admin
privileges. Lets say also that the administrator has spki authority
--- Begin Message ---
What about when a client communicates with a remote server?
For example, a remote policy service, where an admin has decided to update all
nodes with new policy and a process executes that running under admin
privileges. Lets say also that the administrator has spki author
Consider a Subject ProtectionDomain that is added to the stack, instead of
Subject Principals being injected into every domain on the stack:
Subjects don't have code, they lack the ability to use one permission to gain
another, so if a ProtectionDomain representing only a Subject and its
Princi
ssion objects are meant to be immutable so
they should be non blocking, some like SocketPermission aren't
(they wait for dns lookup results if other threads are executing
the same lookup) but with dnsjava they are much better.
So I hope I'm fixing security enough to s
On Jun 30, 2012, at 2:39 AM, Dan Creswell wrote:
> I'd also suggest that too much permission is granted because the current
> Java security infrastructure inevitably works on a highly granular level
> with long lists of detailed security options for this or that. That brings
>
Gonna go inline...
On 28 June 2012 13:32, Peter Firmstone wrote:
> What follows is relatively hard core security, but it's relevant to anyone
> wishing to deploy on untrusted networks. I know some people don't like
> discussing security issues for fear of turning off woul
What follows is relatively hard core security, but it's relevant to anyone
wishing to deploy on untrusted networks. I know some people don't like
discussing security issues for fear of turning off would be developers but
security isn't mandatory, however considering that River/
ot; targeting mechanisms that enable specific types of system
>>> "construction" which in turn can enable specific kinds of "features". Rio
>>> lets you build lots of "small" or "large" services and get all the dynamic,
>>> built
ey
don't want their competition to "see" or "know" how they are using it.
So, there is the whole other side of the internet, on untrusted
networks, where people are constantly using the "Web" for their
transactional, data transport systems/models. I'm
it.
So, there is the whole other side of the internet, on untrusted
networks, where people are constantly using the "Web" for their
transactional, data transport systems/models. I'm not sure where
Jini fits in that world, without some very specific, dedicated systems
t
, data transport
systems/models. I'm not sure where Jini fits in that world, without some very
specific, dedicated systems that do stuff that the web can't do. Looking for
some of that "lone" fruit to pick, is what I'm not sure about.
What kind of transactional, le
I've been thinking about the practicalities of a djinn running in
untrusted networks (internet), the first thing that springs to mind is,
security is much simpler if people can get away with only "dumb" or
reflective proxies.
I'd like to the see the default secu
kup, being poisoned, can cause exploitative code to
> be
> downloaded.
>
> I think that it's vital to understand, that whether you cache the first,
> second
> or fifth lookup, each situation presents a different set of challenges in
> providing security. Ultimately, Jini need
here are others in the Jini
world where the first lookup, being poisoned, can cause exploitative code to be
downloaded.
I think that it's vital to understand, that whether you cache the first, second
or fifth lookup, each situation presents a different set of challenges in
providing sec
ely use equals()?
>>
>
>
> In externally sorted Collections, yes, but not in TreeSet, so that's an
> option, thanks ;) Pays to read the docs properly.
>
>
>>
>>>
>>> With a SecurityManager and our own PolicyFile implementation, it is
>>&g
n, from both ends, but both the
policy and SM must be in place or it won't work. PolicyFile must be
Smells like we're heading towards part of a standard platform. A
security manager and policy generally need to be available to support
downloadable code so I don't see this being
on, from both ends, but both the
> policy and SM must be in place or it won't work. PolicyFile must be
Smells like we're heading towards part of a standard platform. A
security manager and policy generally need to be available to support
downloadable code so I don't see thi
ollection cache with a List based
cache, generate Permissioncollection's on demand. Sort the List after
creation, before publishing, replace the list on write.
Option 2 could be implemented in ConcurrentPermissions, a replacement for
java.security.Permissions.
Option 1 would be implemented b
got two options on how to solve this:
>>
>> 1. Get rid of PermissionCollection based caches altogether and generate
>> PermissionCollection's on demand.
>>
>> 2 Replace the PermissionCollection cache with a List based
>> cache, generate Permissioncollection&#x
y.Permissions.
Option 1 would be implemented by the policy.
In addition, to allow the security manager to cache the results of permission
checks for SocketPermission, I can create a wrapper class, where equals and
hashcode are based purely on the string representation. This allows very rapid
on 2 could be implemented in ConcurrentPermissions, a replacement for
java.security.Permissions.
Option 1 would be implemented by the policy.
In addition, to allow the security manager to cache the results of permission
checks for SocketPermission, I can create a wrapper class, where equals and
That's exactly what I'm thinking, order SocketPermissions first, implemented
using a comparator, add to a new SocketPermissionCollection in order, then
perform the security check.
The comparator can perform the introspection to customise the order for every
securiity check, eg so
Actually, more significantly for me is that the default localhost
SocketPermission is checked before a more lenient SocketPermission. In theory,
one should be able to introspect SocketPermission instances and determine that
one may be automatically implied by the other so can be skipped, possibl
rning off the SocketPermission check, 2) the
RIVER-396 patch and 3) switching JERI to NIO to save some threads.
Chris
-Original Message-
From: Gregg Wonderly [mailto:gr...@wonderly.org]
Sent: Tuesday, December 13, 2011 8:19 AM
To: dev@river.apache.org
Cc: Peter Firmstone
Subject: Re: Im
m: Gregg Wonderly [mailto:gr...@wonderly.org]
Sent: Tuesday, December 13, 2011 8:56 AM
To: dev@river.apache.org
Subject: Re: Implications for Security Checks - SocketPermission, URL and DNS
lookups
Also, one simple reminder about "Windows". The folks at Microsoft want to be
able to make you
ache.org
Subject: Re: Implications for Security Checks - SocketPermission, URL and DNS
lookups
Also, one simple reminder about "Windows". The folks at Microsoft want to be
able to make you buy server class OSes, so the user OSes limit the number of
simultaneous socket connections as well as o
to NIO to save some threads.
Chris
-Original Message-
From: Gregg Wonderly [mailto:gr...@wonderly.org]
Sent: Tuesday, December 13, 2011 8:19 AM
To: dev@river.apache.org
Cc: Peter Firmstone
Subject: Re: Implications for Security Checks - SocketPermission, URL and DNS
lookups
Remember to, f
13, 2011 8:19 AM
To: dev@river.apache.org
Cc: Peter Firmstone
Subject: Re: Implications for Security Checks - SocketPermission, URL and DNS
lookups
Remember to, from a general "workaround" perspective, that you can use command
line options to "lengthen" the time that DNS failure inform
threads.
Chris
-Original Message-
From: Gregg Wonderly [mailto:gr...@wonderly.org]
Sent: Tuesday, December 13, 2011 8:19 AM
To: dev@river.apache.org
Cc: Peter Firmstone
Subject: Re: Implications for Security Checks - SocketPermission, URL and DNS
lookups
Remember to, from a gene
vices) this will drive Reggie's thread count
skyward, perhaps triggering OutOfMemory errors if it's in a 32-bit JVM.
This problem happens in the real world in facilities that allow client
connections to the production LAN, but do not allow the production LAN to
resolve hosts in the client
that allow client connections to the
production LAN, but do not allow the production LAN to resolve hosts in the client LAN.
This may occur due to separate IT teams or strict security rules or simple configuration
errors. Because most client-server systems, like web servers, do not require the serv
d count skyward,
perhaps triggering OutOfMemory errors if it's in a 32-bit JVM.
This problem happens in the real world in facilities that allow client
connections to the production LAN, but do not allow the production LAN to
resolve hosts in the client LAN. This may occur due to separate IT teams
connect,resolve")'. This was difficult to apply to a general
> Sun/Oracle JVM, however, because the default security policy *prepends* a
> ("localhost:1024-","listen") permission that triggers the reverse DNS
> lookup. To avoid this inconvenient setting, I install a
ly to a general Sun/Oracle JVM, however, because the
default security policy *prepends* a ("localhost:1024-","listen") permission
that triggers the reverse DNS lookup. To avoid this inconvenient setting, I
install a new java.security.Policy subclass that delegates to the defaul
o see if the
concurrent policy and executor based security manager are sufficient to
reduce the performance impact for most situations.
Downloaded proxy's that are successfully unmarshalled are automatically
given static Permissions in the ProtectionDomain constructor, but this
is a specif
Actually, my last comment about executor based parallel protection domain
security checks, it is possible (in spite of AccessControlContext being
declared final), by using a domain combiner to merge all protectiondomain's on
the stack into callable tasks and returning one ProtectionDomain
DNS lookups and reverse lookups caused by URL and SocketPermission,
equals, hashCode and implies methods create some serious performance
problems for distributed programs.
The concurrent policy implementation I've been working on reduces lock
contention between threads performing sec
; > Trouble is, none of these old jvm homogenous PermissionCollection's have
> > been
> > exposed to any more than single threads before and the last thing I want to
> > do
> > is reimplement them. They're supposed to be thread safe but many have
>
he last thing I want to do
is reimplement them. They're supposed to be thread safe but many have
visibility issues.
Considering java security policy is a occassional write, multi read, it should
be simple to make it scale very well, using immutability and concurrency utils.
There'
want to do
is reimplement them. They're supposed to be thread safe but many have
visibility issues.
Considering java security policy is a occassional write, multi read, it should
be simple to make it scale very well, using immutability and concurrency utils.
There's just some lega
What about a volatile as the visibility control? Write after update, read
before access? It would at least expose the changes to other threads, not be a
lock, and represent a fairly limited overhead on most hardware.
Gregg
On 10/27/2011 8:55 AM, Peter wrote:
The problem:
Stale references a
The problem:
Stale references allowed and noted in comments:
java.security.Permissions
java.security.BasicPermissions.BasicPermissionCollection
The stale reference in Permissions is an AllPermission object - an
optimisation. If a thread doesn't see the current value, it just checks the
intern
.
>
> Of course, if you're having security problems with LUS registration
> this won't be so helpful (although you'll know which service isn't
> registering and be able to tackle it there and then). Equally, if
> security is a concern, you mightn't be able to regi
're having security problems with LUS registration
this won't be so helpful (although you'll know which service isn't
registering and be able to tackle it there and then). Equally, if
security is a concern, you mightn't be able to register with a logman
either.
On 20 August
Gregg Wonderly wrote:
On 8/18/2011 10:16 PM, Peter Firmstone wrote:
Getting security policies right in a distributed environment is
difficult,
getting information back when things break in deployment is also
difficult.
What would be nice is a service you can utilise to give you a list of
On 8/18/2011 10:16 PM, Peter Firmstone wrote:
Getting security policies right in a distributed environment is difficult,
getting information back when things break in deployment is also difficult.
What would be nice is a service you can utilise to give you a list of failed
security checks and
Getting security policies right in a distributed environment is
difficult, getting information back when things break in deployment is
also difficult.
What would be nice is a service you can utilise to give you a list of
failed security checks and the failed ProtectionDomain&#
Dan Creswell wrote:
Hi Peter,
On 4 August 2011 03:43, Peter Firmstone wrote:
Dan, you're wise and I respect your view.
Thank you equally be careful how much wiseness you attribute to me and
thus how much respect you give me - nobody is perfect! :)
Security matters
Hi Peter,
On 4 August 2011 03:43, Peter Firmstone wrote:
> Dan, you're wise and I respect your view.
>
Thank you equally be careful how much wiseness you attribute to me and
thus how much respect you give me - nobody is perfect! :)
> Security matters to me because I plan
Dan, you're wise and I respect your view.
Security matters to me because I plan to deploy over insecure networks.
Luckily security is mostly complete, Bob Scheifler's team achieved what
they set out to do, a very difficult task I might add. But this takes
skill on the application
.
Shared state can be managed in abstract classes using protected static methods
with synchronization and security checks, all static fields private. Abstract
object state can be similarly manged with protected methods and private fields.
We have the advantage that service api already utilise int
g common superclasses and interfaces in the application, extension or
system classloaders.
Shared state can be managed in abstract classes using protected static methods
with synchronization and security checks, all static fields private. Abstract
object state can be similarly manged with p
On 7/31/2011 5:35 AM, Peter Firmstone wrote:
I think this would be useful in an internet environment, where a developer wants
to export an object and hand it as a parameter to another service, and have it
unexported automatically when no longer required.
This is why I make my smart proxy classe
s on
behalf of the application. In the traditional RMI DGC model, those calls happen implicitly as
remote references appear and disappear from a JVM. But in the JERI security model, the client
application controls the security behavior of remote calls by explicitly (with respect to the
standard
.
2. The node then looks up a Security Policy Advisory service, it
chooses one that can authenticate as an Administrator.
3. The client node then hands back a proxy (RemotePolicy service)
that the SecurityPolicyAdvisory service (using MethodConstraints
again to restrict access
1 - 100 of 130 matches
Mail list logo
