qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kerry Bonin <kerrybo...@gmail.com>
Subject Re: Access to qpidd original arg list from {platform specific}QpiddBroker.cpp ?
Date Fri, 02 Apr 2010 16:38:02 GMT
One question - should I create a new jira, or use an existing, to submit the
patch ?

On Fri, Apr 2, 2010 at 11:34 AM, Steve Huston <shuston@riverace.com> wrote:

> Thanks for checking into best practices here, Kerry!
>
> -Steve
>
> > -----Original Message-----
> > From: Kerry Bonin [mailto:kerrybonin@gmail.com]
> > Sent: Friday, April 02, 2010 11:33 AM
> > To: dev@qpid.apache.org
> > Subject: Re: Access to qpidd original arg list from {platform
> > specific}QpiddBroker.cpp ?
> >
> >
> > FWIW, I've been doing some reading, and talking to friends
> > who are still active on the exploit side of the security
> > world, and they've convinced me the default user should be
> > NetworkService.  Short version is a) it is the official
> > Microsoft recommendation, and b) all the attack plans post
> > process injection / remote execution begin with privilege
> > escalation, so its best if your process starts with the
> > lowest possible local privileges.  In the real world once
> > process injection / remote execution is achieved there are so
> > many unpatched privilege escalation vectors on Windows that a
> > network service has already lost the machine, so you might as
> > well make the next step as hard as possible.
> >
> > Account, password and depends now work (and are delivered to
> > our test team), looking at QPID-1423 today...
> >
> > On Thu, Apr 1, 2010 at 4:27 PM, Steve Huston
> > <shuston@riverace.com> wrote:
> >
> > > This sounds great, Kerry. Looking forward to seeing it.
> > >
> > > -Steve
> > >
> > > > -----Original Message-----
> > > > From: Kerry Bonin [mailto:kerrybonin@gmail.com]
> > > > Sent: Thursday, April 01, 2010 1:30 PM
> > > > To: dev@qpid.apache.org
> > > > Subject: Re: Access to qpidd original arg list from {platform
> > > > specific}QpiddBroker.cpp ?
> > > >
> > > >
> > > > LocalService still has access to the network, and is generally
> > > > preferable over NetworkService - NetworkService tries to use the
> > > > domain account privileges it is running under, whereas
> > LocalService
> > > > is treated as an anonymous network agent.  A hacked
> > service running
> > > > under NetworkService will therefore have more privileges in the
> > > > local network than one running under LocalService, so unless you
> > > > need to interact with the domain, LocalService is preferred for
> > > > network services.
> > > >
> > > > On the service abstraction issue, I've now been able to
> > contain all
> > > > the Windows service code to the Windows specific QpiddBroker.cpp,
> > > > and reverted all my changes to qpidd.cpp. (Although I am adding a
> > > > WinService .cpp/.h with my generic service helper class.)  So the
> > > > platform abstraction is as clean as possible on the
> > Windows side.
> > > > The only other interaction between the service code and
> > the broker
> > > > is during shutdown, in which case I preserve the Broker *
> > and call
> > > > the
> > > > shutdown() API.
> > > >
> > > > I've added --start-type={auto|demand|disabled}, and now
> > working on
> > > > --account, --password, and --depends (register list of dependent
> > > > services), all as per SCM conventions. Also looking at
> > QPID-1423...
> > > >
> > > >
> > > > On Thu, Apr 1, 2010 at 12:14 PM, Andrew Stitcher
> > > > <astitcher@redhat.com>wrote:
> > > >
> > > > > On Thu, 2010-04-01 at 11:46 -0500, Kerry Bonin wrote:
> > > > > > There is a UAC issue on installing a service, in that if
> > > > you try and
> > > > > > use
> > > > > the
> > > > > > --install command while logged in as a user that does
> > not have
> > > > > > the
> > > > > privilege
> > > > > > to install services, it will (properly) fail.  So that is
> > > > working as
> > > > > > it should - in our testing here we use that command
> > during our
> > > > > > installation process, which is running with elevated
> > > > privileges, so
> > > > > > it works at that time, as it should.
> > > > > >
> > > > > > As for normal use, I have the broker by default install
> > > > itself under
> > > > > > the LocalSystem account, which IIRC is the recommended
> > > > account for
> > > > > > services,
> > > > > and
> > > > > > this account has reduced privileges on later Windows.  If
> > > > you NEED
> > > > > > to run
> > > > > it
> > > > > > with more or less privileges, you can create or use
> > an existing
> > > > > > account appropriately, and just tell the broker to use
> > > > that account
> > > > > > - you only
> > > > > need
> > > > > > to provide the credentials once, and Windows SCM manages
> > > > the token
> > > > > > generation and caching as per normal SCM rules, and
> > when you try
> > > > > installing
> > > > > > it you would obviously need sufficient rights to use that
> > > > > > account AND install a service.
> > > > >
> > > > > Doesn't it have to be the 'NETWORK SERVICE' account for
> > it to have
> > > > > access to the network? which you'd think it would need! In
> > > > more recent
> > > > > versions of windows the service accounts are split.
> > > > >
> > > > > >
> > > > > > I'm pretty sure this all meets guidelines, as I'm never
> > > > > > violating any security rules that I know of...  (and I'm a
> > > > > > hardcore
> > > > security /
> > > > > > crypto geek, 25+ years...)
> > > > > >
> > > > > > If you would like me to disable the self-installation
> > features
> > > > > > before
> > > > > patch,
> > > > > > I certainly can...
> > > > >
> > > > > No need, I was working from a faulty memory, and I can't
> > > > think of any
> > > > > good reason to exclude this functionality. I suspect the
> > > > much bigger
> > > > > issue is going to be how the Unix daemonisation and the Windows
> > > > > service code are both abstracted so that the code
> > becomes easier
> > > > > to maintain.
> > > > >
> > > > > Andrew
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > --------------------------------------------------------------------
> > > > -
> > > > > Apache Qpid - AMQP Messaging Implementation
> > > > > Project:      http://qpid.apache.org
> > > > > Use/Interact: mailto:dev-subscribe@qpid.apache.org
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > Apache Qpid - AMQP Messaging Implementation
> > > Project:      http://qpid.apache.org
> > > Use/Interact: mailto:dev-subscribe@qpid.apache.org
> > >
> > >
> >
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message