On the topic of security, most *nix installations, including Linux, deny an
application the ability to write to itself or its tree. This is to prevent
a discovered exploit from modifying the applications code and causing it do
do whatever the hacker wants (crash, access stuff it shouldent,...).
We have denied jBoss write privilidge to itself and only allow it to write
where it needs to. It may be a bad idea to allow jBoss to modify its own
jcml file (we have disabled the auto jcml feature) or to replace executable
modules that comprise it.
OTOH, it may not be such a bad idea for a seperate process to have
privilidge to do this, since it would need only be invoked when its time to
upgrade jBoss.
Just my 2 cents...
Jim
--On Tuesday, June 12, 2001 10:14 AM +0100 Mike Swainston-Rainford
<[EMAIL PROTECTED]> wrote:
> From my experiences at security aware sites (like financial
> institutions) I'd say that a file of the node specific properties is a
> must. Port numbers have been mentioned but what about the DB user and
> password?
>
> Access to these leaves the database wide open so they would often not
> even be held in a file on the file system but typed in during a
> deployment or startup. If they are put in a file then it lives only on
> the node to which it applies protected under a secure user id that's used
> solely for deployment of the application server.
>
> The DB user id and password are currently stored in JBoss.jcml. They
> would need to be pulled out, as suggested for the port numbers, into a
> separate properties file before the more paranoid sites I've worked at
> would consider deploying JBoss.
>
> Mike S-R
>
> At 00:05 12/06/2001 -0700, you wrote:
>> We can argue the details, but I agree with Peter about the current
>> configuration
>> being very difficult to manage. If we are going to move to a web based
>> deployment
>> to multiple boxes we won't be able to simply rely on URLClassLoaders
>> pulling down the current config files and expect them to work as many
>> configuration parameters will be specific to box on which the server is
>> being installed.
>>
>> ----- Original Message -----
>> From: "Peter Antman" <[EMAIL PROTECTED]>
>> To: <[EMAIL PROTECTED]>
>> Sent: Monday, June 11, 2001 11:30 PM
>> Subject: Re: [JBoss-dev] JMSContainerInvoker.java
>>
>>
>> > On 11 Jun, marc fleury wrote:
>> > > what I am hearing is that you want jbossmq/jboss/servlet
>> > > configuration in xml snippets in jboss.jcml, otherwise I don't see
>> > > what it brings
>> except yet
>> > > another layer of indirection...
>> >
>> >
>> > I guess it depends on you requirements. Mine is that I must be able to
>> > support a lot of installations of JBoss on machines I do not have
>> > complete controll over, such as ports, multihomed and such things.
>> >
>> > My experience from working with JBoss for almost a year now is that the
>> > configuration files changes a lot al the time, and it is quite hard to
>> > diff all these files all the time when a new release arrives, or when I
>> > have to go cutting cvs edge ;-).
>> >
>> > It is much easier to have one central property files wich controlles
>> > all those environment stuff (much like a preprocessor), just try to
>> > diff standardjboss.xml with all those hardcoded
>> > <RMIObjectPort>4444</RMIObjectPort>!
>> >
>>
>>
>>
>> _______________________________________________
>> Jboss-development mailing list
>> [EMAIL PROTECTED]
>> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
********************************************
I shall be telling this with a sigh
Somewhere ages and ages hence:
Two roads diverged in a wood, and I -
I took the one less traveled by,
And that has made all the difference.
- Robert Frost, 1916
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
