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 15:32:52 GMT
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
>
>

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