You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Kerry Bonin <ke...@gmail.com> on 2010/04/01 18:46:33 UTC
Re: Access to qpidd original arg list from {platform
specific}QpiddBroker.cpp ?
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.
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...
Kerry
On Thu, Apr 1, 2010 at 9:33 AM, Andrew Stitcher <as...@redhat.com>wrote:
> On Tue, 2010-03-30 at 11:21 -0500, Kerry Bonin wrote:
> > Hello, and thanks for the comments!
> >
> > First, thank you Andrew for GetCommandLine() - 20 something years on
> > Windows, and I don't remember seeing that one before, certainly made this
> > simpler.
> >
> > On the subject of the command line in general for a service - I agree
> that
> > under most normal use a config file should be used, I just wanted to make
> > sure the command line was usable...
> >
> > On the security of self-installing services - if the service is doing
> much
> > more than installing itself, especially if it contains baked in
> credentials,
> > ect., that would be a very bad thing. What I've done is essentially the
> > equivalent of sc create|start|stop|delete wrap as a convenience function,
> > nothing more, and the calls execute with the same privilege level a user
> has
> > available to them at the command line.
>
> ISTR that the issue is related to UAC, but I admit I can't quite see
> what the issue could be.
>
> One security related issue I'd suggest is that if running qpid as a
> service then we should run as an unprivileged user though with network
> access. qpidd only shuffles bits around a network so doesn't seem to
> need elevated privileges.
>
> I'm not sure how this fits exactly, but I assume that you'd need to
> create a new user account on installation and run the service using it.
> This would obviously require admin privileges.
>
> Andrew
>
>
>
> ---------------------------------------------------------------------
> 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
>
>
RE: Access to qpidd original arg list from {platform specific}QpiddBroker.cpp ?
Posted by Steve Huston <sh...@riverace.com>.
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 Kerry Bonin <ke...@gmail.com>.
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
>
>
Re: Access to qpidd original arg list from {platform
specific}QpiddBroker.cpp ?
Posted by Andrew Stitcher <as...@redhat.com>.
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