Re: exec.basic - comments please

["Mal Lansell" <mal@xxxxxxxxxxx>]

Actually, I've persuaded myself otherwise!

There *will* be a list of approved applications.  This may not guard
against an xpl virus, but it will offer some additional protection
against messages originating from outside.

The list will not be editable via the normal config route, since
this would render it useless.  I'm going to write a simple config
dialog to go with this one.  I've also been thinking that an xPL
control panel plugin would be nice, but I need to read up a bit more
to see if other vendors can add tabs for their own apps first.

Mal






--- In ukha_xpl@xxxxxxx, "Mal Lansell" <mal@l...> wrote:
>
>
> 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.
> > > ________________________________
> > >
> >
>