qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Huston" <shus...@riverace.com>
Subject RE: Access to qpidd original arg list from {platform specific}QpiddBroker.cpp ?
Date Fri, 02 Apr 2010 16:34:21 GMT
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
View raw message