Re: exec.basic - comments please

["Mal Lansell" <mal@xxxxxxxxxxx>]

OK, this is what I'm going to do:

1) No program list - it just doesn't help.

2) Rely on ListenTo to block unwanted message sources.

3) Add a page to the installer that warns of the security issues and
how to deal with them.  The same information will go into the readme
and onto the xPLExec web page.

I think this will be sufficient, unless someone wants to have
another go at persuading me otherwise :-)

As for log.basic - should I use these exclusively as the reponse to
exec commands, or only for reporting errors?  My initial feeling is
to send the exec.basic status as outlined before, and just send a
log.basic message when an app fails to spawn (so two messages would
be sent in that case, a log.basic and an exec.basic)

Mal




--- In ukha_xpl@xxxxxxx, Tom Van den Panhuyzen <tomvdp@g...>
wrote:
>
> My view on the "xpl-virus": the only concern is rogue
xpl-packets
> entering the "secured" network.  That is why ListenTo was
introduced.
> A rogue xpl-application inside the network would be a very
inefficient
> thing... it could just call format c: directly.
> So I don't think we need lists of allowed programs etcetera.  Keep
it simple.
>
> Another point: please send out log.basic messages when the launched
> application returns an error.  We should try to make more use of
this
> schema so that all xpl applications (or applications launched via
xpl)
> log to some central point (by using the xpllogger f.e.).  It makes
> maintenance a lot easier.
>
> Tom
>
>
> On 10/26/05, Mal Lansell <mal@l...> wrote:
> > Gerry Duprey wrote:
> >
> > > Howdy,
> > >
> > > >     pid=num       //integer identifier (<2^32)
> > >
> > > Based on the comments below, any reason the pid has to be a
number?
> > > Since
> > > it's meant to just be a unique identifier, why not let it be
whatever the
> > > initiator wants.  If they want a number, great.  If they
want
to use the
> > > name of the program as a pid, great.  They important point,
to
me, is
> > > that
> > > it's some sort of unique identifier with meaning only to the
initiator
> > > and
> > > as such, the xplExec service shouldn't impose any meaning
(even that
> > > it has
> > > to be numeric) on it -- just record it and spit it back in
> > > status/trigger notes.
> > >
> > Seems completely reasonable to me - but I'll still include the
program
> > name in the status message too.
> >
> > > > Program is the name of the executable file to run,
without
any path.
> > >
> > > Hmmm, I agree about the possibility of running unwanted
programs.
> > > Perhaps
> > > the xPLExec program could have a series of config items that
either
> > > listed
> > > all possible executable programs (i.e. if the program is not
listed, it
> > > can't be run) or something like that.  I suspect being able
to
run an
> > > arbitrary program isn't going to be a great thing, and the
actual
> > > number of
> > > programs to run is probably pretty low.
> > >
> > The way I see the security issue is that there are two ways to
attack
> > via xPL.  One is via open ports from the internet, the other is
by
> > installing a rogue application.  I don't think we should concern
> > ourselves with rogue applications since they can run other
programs
> > directly - they don't need xPL to do it for them!  In any case,
an
> > xPL-specific virus will know where to look for any list of
trusted
> > programs we try to create.
> >
> > As for the internet attack route - isn't that what the ListenTo
> > addresses are there to prevent?
> >
> > 8< snip
> >
> > >
> > > Hmmm, in the interests of cross platform use of this schema,
perhaps the
> > > actual error message contents shouldn't be declared here.
Different O/Ss
> > > are going to have different failure codes/descriptions and
they may
> > > not be
> > > mappable (and in the case of a Java version, you'd have to
build in every
> > > conceivable platforms mappings so it could be cross platform
and sort of
> > > kills the xplatform idea :-)  Having an error message item
is
good as the
> > > initiator can use it to log a message, display an error,
etc.
But other
> > > than it being present, implying meaning on it seems
problematic to me.
> > >
> > I should have made clear that those error values are set by my
> > Windows-based xPLExec app and not part of the schema - the
schema just
> > includes return= which could be anything at all (it's for the
original
> > sender to interpret according to the system its running on etc).
> >
> > Mal
> >
> >
> >
> > xPL Links: http://www.xplproject.org.uk http://www.xplhal.com
> > http://www.xpl.myby.co.uk
> > To Post a Message: ukha_xpl@xxxxxxx
> > To Subscribe:  ukha_xpl-subscribe@xxxxxxx
> > To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx
> >
> >
> >
> > ________________________________
> > YAHOO! GROUPS LINKS
> >
> >  Visit your group "ukha_xpl" on the web.
> >
> >  To unsubscribe from this group, send an email to:
> >  ukha_xpl-unsubscribe@xxxxxxx
> >
> >  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
> >  To unsubscribe from this group, send an email to:
> >  ukha_xpl-unsubscribe@xxxxxxx
> >
> >  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
> >  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
> > ________________________________
> >
>