You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Steve Huston <sh...@riverace.com> on 2010/04/01 23:27:02 UTC
RE: Access to qpidd original arg list from {platform specific}QpiddBroker.cpp ?
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
> <as...@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
RE: Access to qpidd original arg list from {platform specific}QpiddBroker.cpp ?
Posted by Steve Huston <sh...@riverace.com>.
> One question - should I create a new jira, or use an
> existing, to submit the patch ?
I don't think there's an exising JIRA for adding service capability for
the broker, so unless you have found one, please enter a new one.
Thanks,
-Steve
> On Fri, Apr 2, 2010 at 11:34 AM, Steve Huston
> <sh...@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
> <sh...@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
> > > > > <as...@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
> >
> >
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Access to qpidd original arg list from {platform
specific}QpiddBroker.cpp ?
Posted by Kerry Bonin <ke...@gmail.com>.
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 <sh...@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
> > <sh...@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
> > > > <as...@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
>
>
RE: Access to qpidd original arg list from {platform specific}QpiddBroker.cpp ?
Posted by Steve Huston <sh...@riverace.com>.
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
> <sh...@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
> > > <as...@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
Re: Access to qpidd original arg list from {platform
specific}QpiddBroker.cpp ?
Posted by Kerry Bonin <ke...@gmail.com>.
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 <sh...@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
> > <as...@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
>
>