Deleting extended stored procedures in master

Hello
Our Audit group is requiring us to delete many extended stored procedures in
the master database. If you google something to that effect you will see
the list all over the Net of the specific procedures that are recommended
for deletion. You will also see the comment that deleting some of them can
break SQL Server functionality, etc... We deleted all of the
recommendations on a test server and had problems with log shipping, viewing
Agent properties, setting up new users, viewing SQL Server logs, etc. So we
added back xp_regread, xp_availablemedia, xp_getnetname, xp_ntsecenumdomains
and a few more to get those basic functions working again. I sense that
those other registry procedures are used by SQL Server upgrades/service
packs/security patches but we haven't tested that yet.
Has anyone documented what procedure breaks what function? I can see a
whole lotta testing that we'll have to do to put SQL Server through its
paces to see what breaks if we are forced to delete all these procedures.
Documentation on the xps seems a bit sparse from what I can tell.
Ultimately, if they are locked down in master I'm not convinced they should
be deleted. If someone gets as far as master, they could just add them back
anyway. Am I just being naive?
SteveIt's a fairly pointless exercise that leaves you in an unsupported
configuration which should factor into such a decision. The list of extended
procedures with public execute permissions is fairly small and relatively
benign. Plus, if you are running the SQL Service under a non admin domain
account the reach of some that are still public such as xp_regread or
xp_getfiledetails are further curtailed. Do any of your Audit group actually
have any real experience with SQL Server?
HTH
Jasper Smith (SQL Server MVP)
http://www.sqldbatips.com
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Steve" <pezguy@.mn.rr.com> wrote in message
news:1Vuge.53142$215.38295@.tornado.rdc-kc.rr.com...
> Hello
> Our Audit group is requiring us to delete many extended stored procedures
> in the master database. If you google something to that effect you will
> see the list all over the Net of the specific procedures that are
> recommended for deletion. You will also see the comment that deleting
> some of them can break SQL Server functionality, etc... We deleted all
> of the recommendations on a test server and had problems with log
> shipping, viewing Agent properties, setting up new users, viewing SQL
> Server logs, etc. So we added back xp_regread, xp_availablemedia,
> xp_getnetname, xp_ntsecenumdomains and a few more to get those basic
> functions working again. I sense that those other registry procedures are
> used by SQL Server upgrades/service packs/security patches but we haven't
> tested that yet.
> Has anyone documented what procedure breaks what function? I can see a
> whole lotta testing that we'll have to do to put SQL Server through its
> paces to see what breaks if we are forced to delete all these procedures.
> Documentation on the xps seems a bit sparse from what I can tell.
> Ultimately, if they are locked down in master I'm not convinced they
> should be deleted. If someone gets as far as master, they could just add
> them back anyway. Am I just being naive?
> Steve
>|||Do any of the Audit group have real experience with SQL Server? LOL...it
doesn't appear that way from what I can tell. Part of trying to convince
them that this is a silly requirement is to tell them how it breaks SQL
Server. Thanks for your comments Jasper!
"Jasper Smith" <jasper_smith9@.hotmail.com> wrote in message
news:OAZylwnVFHA.1152@.tk2msftngp13.phx.gbl...
> It's a fairly pointless exercise that leaves you in an unsupported
> configuration which should factor into such a decision. The list of
> extended procedures with public execute permissions is fairly small and
> relatively benign. Plus, if you are running the SQL Service under a non
> admin domain account the reach of some that are still public such as
> xp_regread or xp_getfiledetails are further curtailed. Do any of your
> Audit group actually have any real experience with SQL Server?
> --
> HTH
> Jasper Smith (SQL Server MVP)
> http://www.sqldbatips.com
> I support PASS - the definitive, global
> community for SQL Server professionals -
> http://www.sqlpass.org
> "Steve" <pezguy@.mn.rr.com> wrote in message
> news:1Vuge.53142$215.38295@.tornado.rdc-kc.rr.com...
>|||I have to deal with similar groups were I work so am glad it's not just us
that have to suffer :-) It's all about risk and I would say the risk of
leaving these extended procs in place is extremely low if you factor in the
fact that PSS would probably be perfectly within their rights to refuse to
support such a configuration (not saying they would but they could) if you
did have a real issue. I would certainly press for a list of exploits that
these expose the server to. Too often security/audit departments lay down
rules with no real knowledge or understanding of the product in question and
without any real word basis for the restrictions they want to impose.
Generally the restrictions simply hamper the teams that have to support the
application rather than alleviate any security risk.
HTH
Jasper Smith (SQL Server MVP)
http://www.sqldbatips.com
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Steve" <pezguy@.mn.rr.com> wrote in message
news:qwOge.7$bn.2@.tornado.rdc-kc.rr.com...
> Do any of the Audit group have real experience with SQL Server? LOL...it
> doesn't appear that way from what I can tell. Part of trying to convince
> them that this is a silly requirement is to tell them how it breaks SQL
> Server. Thanks for your comments Jasper!
> "Jasper Smith" <jasper_smith9@.hotmail.com> wrote in message
> news:OAZylwnVFHA.1152@.tk2msftngp13.phx.gbl...
>sql