Hi,

I created a Jira issue for that : https://jira.nuxeo.org/browse/NXP-5019
I will commit this morning, let me know if this solves the issue for you.

Tiry

On 14 April 2010 15:27, Nel Taurisson <[email protected]> wrote:

> Hi again,
>
> Thanks for your answer.
>
> > Furthermore, the default Nuxeo/JBoss config is to bind listening port on
> > local IPs only.
> > => This is a explicit configuration choice to make the listening ports
> open
> > to all IPs
>
> Listening only on local port is ok when accessing only to the webapp
> as apache (or another) handles it. But our problem is to give access
> to the repo from another class of client, not a webapp client but
> somethong else (specifically where working on ftp access to the repo).
> Whats the "clean way" to do it for you if you cannot require a login ?
>
> > You can configure that at Jboss level as Alex suggested.
>
> I think I've missed Alex suggestion, what was it ?
>
> > What we could do in Nuxeo, is add a config parameter to disable system
> login
> > from a remote host.
> > => would that be ok for you ?
>
> That would be nice yes.
>
> Thanks again.
>
> Nel
>
>
>
>
>
>
>
>
>
>
>
> 2010/4/14 Thierry Delprat <[email protected]>:
> > Hi Nel,
> > I answered inline ...
> > On 14 April 2010 11:12, Nel Taurisson <[email protected]> wrote:
> >>
> >> Hi,
> >>
> >> I'm very surprised that its not an issue for you. I'm very frightened
> >> because, anyway I look to the problem, all I can see is a grave
> >> security risk.
> >>
> >> 1) "In most of the cases, the Nuxeo Server is behind a firewall and a
> >> reverse proxy" : so this is not a choice, this is mandatory. If it is
> >> not installed this way, we have a huge security hole.
> >
> > I am not aware of anyone setting up a production serveur not configuring
> > reverse proxy and firewall.
> > This is not specific to Nuxeo, this is part of the standard security
> rules
> > for all web applications.
> > Furthermore, the default Nuxeo/JBoss config is to bind listening port on
> > local IPs only.
> > => This is a explicit configuration choice to make the listening ports
> open
> > to all IPs
> >>
> >> But still, if someone gets access to the server, he can still execute
> >> malicious code and can breaks the repo.
> >
> > True.
> > I usually consider that if someone "bad"  can log on the server at OS
> level
> >  : then you are lost.
> > You can slow it down, but you can not prevent him from breaking the
> server.
> >
> >>
> >> 2) "either RMI access are limited to a sub LAN or RMI access go
> >> through a VPN" : the security hole remains, everybody on your lan can
> >> execute system code on your repository. If you  open the RMI acces,
> >> your security policy is uniquely based on the trust you have on your
> >> users
> >>
> >> So, in my opinion, as is :
> >>  - there is no way to secure a nuxeo installation,
> >>  - the RMI access is useless as potentially dangerous
> >>
> >> Can you give an hint on how to get the rmi connection require a
> >> user/password auth. It must not be very complicated as a
> >> login/password can be used. So the point is just to implement a way of
> >> making it mandatory.
> >
> >
> > You can configure that at Jboss level as Alex suggested.
> > What we could do in Nuxeo, is add a config parameter to disable system
> login
> > from a remote host.
> > => would that be ok for you ?
> >
> >>
> >> Thanks a lot.
> >>
> >> Nel
> >>
> >>
> >>
> >>
> >>
> >>
> >> 2010/3/26 Thierry Delprat <[email protected]>:
> >> > Hi Nel,
> >> > In most of the cases, the Nuxeo Server is behind a firewall and a
> >> > reverse
> >> > proxy, so this is not an issue.
> >> > For projets using RMI access :
> >> >  - either RMI access are limited to a sub LAN (typically Server to
> >> > Server
> >> > communication)
> >> >  - or RMI access go through a VPN (Client to Server communication,
> >> > because
> >> > RMI is not NATable)
> >> > So if neither of the solution is applicable for you, you will have to
> >> > tweak
> >> > the LoginModule to add a Shared secret check.
> >> > We'll be glad to help you on that, but until then never had the
> >> > requirement.
> >> > Tiry
> >> > On 26 March 2010 17:54, Nel Taurisson <[email protected]>
> wrote:
> >> >>
> >> >> Ok, thanks.
> >> >>
> >> >> But then how can we secure the repository from malicious code but
> >> >> still giving a remote access to a nuxeo client app we wrote ?
> >> >>
> >> >> Thanks a lot.
> >> >>
> >> >> Nel
> >> >>
> >> >> 2010/3/25 Florent Guillaume <[email protected]>:
> >> >> > Did you actually get an answer?
> >> >> > The short one is that no, it's not possible: Nuxeo Shell uses JBoss
> >> >> > Remoting, which is designed as an equivalent to RMI and provides
> >> >> > roughly full JVM access. So even if the shell superficially
> required
> >> >> > credentials, underlying this the protocol would still be open to
> >> >> > someone that compiled his own shell.
> >> >> >
> >> >> > Florent
> >> >> >
> >> >> > On Mon, Mar 22, 2010 at 5:35 PM, Nel Taurisson
> >> >> > <[email protected]>
> >> >> > wrote:
> >> >> >> Sorry, hit the button to fast.
> >> >> >>
> >> >> >> Thanks a lot for your answers.
> >> >> >> Regards
> >> >> >>
> >> >> >> Nel
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> 2010/3/22 Nel Taurisson <[email protected]>:
> >> >> >>> Hi,
> >> >> >>>
> >> >> >>> It seems to me that it is possible to connect to a remote nuxeo
> >> >> >>> repo
> >> >> >>> without any credential and have full read / write access to the
> >> >> >>> repo.
> >> >> >>>
> >> >> >>> Maybe I'm missing a configuration property or something, but I'm
> >> >> >>> affraid I can execute the following code either on nuxeo 5.2 or
> 5.3
> >> >> >>> :
> >> >> >>>
> >> >> >>> Collection<File> files = null;
> >> >> >>>        String bundles = System.getProperty("nuxeo.bundles");
> >> >> >>>        if (bundles != null) {
> >> >> >>>            files = NuxeoApp.getBundleFiles(new File("."),
> bundles,
> >> >> >>> ":");
> >> >> >>>        }
> >> >> >>>
> >> >> >>>        NuxeoApp app = new NuxeoApp();
> >> >> >>>        app.start();
> >> >> >>>
> >> >> >>>        if (files != null) {
> >> >> >>>            app.deployBundles(files);
> >> >> >>>        }
> >> >> >>>
> >> >> >>>        NuxeoClient client = NuxeoClient.getInstance();
> >> >> >>>
> >> >> >>>        client.tryConnect("localhost", 62474);
> >> >> >>>
> >> >> >>>        RepositoryInstance repo = client.openRepository() ;
> >> >> >>>        CoreSession documentManager = repo.getSession() ;
> >> >> >>>
> >> >> >>>        DocumentModel doc = documentManager.getDocument( new
> >> >> >>> PathRef(
> >> >> >>> "/default-domain" ) ) ;
> >> >> >>>        doc.setPropertyValue( "dc:description" , "I could have
> >> >> >>> killed
> >> >> >>> your repo" ) ;
> >> >> >>>        doc = documentManager.saveDocument( doc ) ;
> >> >> >>>        documentManager.save() ;
> >> >> >>>
> >> >> >>>        System.out.println(     documentManager.getDocument( new
> >> >> >>> PathRef(
> >> >> >>> "/default-domain" ) ).getPropertyValue( "dc:description" ) ) ;
> >> >> >>>
> >> >> >>>        repo.close() ;
> >> >> >>>
> >> >> >>
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Florent Guillaume, Director of R&D, Nuxeo
> >> >> > Open Source, Java EE based, Enterprise Content Management (ECM)
> >> >> > http://www.nuxeo.com   http://www.nuxeo.org   +33 1 40 33 79 87
> >> >> >
> >> >> _______________________________________________
> >> >> ECM mailing list
> >> >> [email protected]
> >> >> http://lists.nuxeo.com/mailman/listinfo/ecm
> >> >> To unsubscribe, go to http://lists.nuxeo.com/mailman/options/ecm
> >> >
> >> >
> >
> >
>
_______________________________________________
ECM mailing list
[email protected]
http://lists.nuxeo.com/mailman/listinfo/ecm
To unsubscribe, go to http://lists.nuxeo.com/mailman/options/ecm

Reply via email to