OK, I can reproduce this behavior: by giving the service the same permissions as the secret services, I can make it disappear from the list in services.msc.
sc sdset myservice D:(D;;DCLCWPDTSD;;;IU)(D;;DCLCWPDTSD;;;SU)(D;;DCLCWPDTSD;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)
So it all depends on permissions.
OK, expand this line of the security descriptor. This is a little tricky because the mapping between SDDL permissions and equivalent Security Manager permissions is not well documented in MSDN or in the SDK headers; fortunately, Wayne Martin has already made a difficult climb for us and posted the results on the blog entry "Service Manager Control" for non-admins .
D: - this part is the DACL, the permissions on the service.
Negative entries always come first, which also means that they take precedence over allow elements:
(D;;DCLCWPDTSD;;;IU) - deny (D) interactive users (IU) the following rights: DC - SERVICE_CHANGE_CONFIG (the right to change the service configuration) LC - SERVICE_QUERY_STATUS (the right to query the service status) WP - SERVICE_STOP (the right to stop the service) DT - SERVICE_PAUSE_CONTINUE (the right to pause and continue the service) SD - DELETE (the right to delete the service) (D;;DCLCWPDTSD;;;SU) - deny services (SU) the same set of rights as above (D;;DCLCWPDTSD;;;BA) - deny the Administrators group (BA) the same as above
Allow entries are the same as default permissions. (They are in a different order, but the order of the allowed entries does not matter.)
(A;;CCLCSWLOCRRC;;;IU) - allow the interactive user the following rights: CC - SERVICE_QUERY_CONFIG (the right to query the service configuration) LC - overridden by the deny entry SW - SERVICE_ENUMERATE_DEPENDENTS (the right to see service dependencies) LO - SERVICE_INTERROGATE (the right to send SERVICE_CONTROL_INTERROGATE) CR - SERVICE_USER_DEFINED_CONTROL (the right to send a user defined control) RC - READ_CONTROL (the right to see the permissions) (A;;CCLCSWLOCRRC;;;SU) - allow services the following rights: same as for the interactive user (A;;CCLCSWRPWPDTLOCRRC;;;SY) - allow local system the following rights: same as for the interactive user, plus: RP - SERVICE_START (the right to start the service) WP - overridden by the deny entry for BA DT - overridden by the deny entry for BA (A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA) - allow the Administrators group: same as for local system, plus: DC - overridden by the deny entry LC - overridden by the deny entry SW - overridden by the deny entry SD - overridden by the deny entry WD - WRITE_DAC (permission to change the permissions) WO - WRITE_OWNER (permission to take ownership)
Finally, we have SACL. It also does not change from the default value for the service.
S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD) S: - indicates that this is a SACL AU - indicates that this is an audit entry FA - indicates that failed attempts to access the object should be audited WD - controls whose failed attempts should be audited; the Everyone SID CCDCLCSWRPWPDTLOCRSDRCWDWO - the kinds of access attempts to audit - appears to include every right that applies to services
So basically it just says: "Audit all failed access attempts to this service."
It should be possible to greatly simplify these permissions, for example by removing all permissions that are overridden by deny permissions. Actually, it seems that the only access right that you really need is SERVICE_START and maybe SERVICE_QUERY permission for the local system, and maybe not even those .:-)
On the other hand, the complexity of permissions is not a big deal, so you probably shouldn't try to test the changes.
PS: to restore the default permissions, which you can say:
sc sdset myservice D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)