Not only this, but if the workstations are members of a domain with domain trust: Server Manager is able to see -all- computers in the domain (any domain connected to the network, actually), and is able to access the Services control panel (if the current login has either Domain Admins group, Administrators group, or the Administrator password for the remote system). Which can just change the startup for the service on the remote system anyway. And let's not forget remote registry editing capability! Change the startup for SMS Client to 0x0010 (I think), and it gets set to start Automatically. There -is- no definitive guide to how Microsoft security interacts in networked environments. PLUS: SMS offers the capability to run commands on the remote system as though they were run locally!!! No need to have 'lockup' and 'reboot' as integral parts of the service, since anything can be run anyway -- and anything can be copied, and anything can be marked executable. Whee. Microsoft, you're gonna have to eat crow on this one. -Winged
Ah, public key management. The bane of public key cryptosystems.
First, some definitions to make my words have more meaning:
Alice, Bob, Carol, David, Elaine, Frank: Persons A through F in a public key cryptosystem world. Assume that all of them have at least one public/private key pair, and that they know not to give out their public keys. Also assume (unless told otherwise) that they are trying to play fair.
Eve: An 'eavesdropper', one who listens to the message traffic, but who can't alter it for any reason. This person is a snoop, just wanting to get information that isn't supposed to be accessible.
Mallory: A 'malicious' user of the system, someone who actively tries to break the system for whatever purpose. He is assumed to be all-powerful (able to change contents of files on public networks, alter bit traffic on networks, and so on), but not all-knowing (he doesn't know the users' secret or private keys).
Trent: A 'trusted authority' who acts like a notary public for the keys the users are using.
Secret key: Used in symmetric cryptosystems, both parties must have this key to encrypt or decrypt.
Private key: One half of a public/private key pair, the half that should NEVER be made common knowledge.
Public key: One half of a public/private key pair, the half that should be made common knowledge so that people can check your signatures, decrypt messages from you, etc.
Certificate: A 'signed statement', like Trent's notarization, saying that a given public key belongs to who it says it does.
And that should do it for the definitions. Now, onto the public key management systems:
There are three different ways that public keys management can be handled.
1) Each user can have a copy of the entire public key database, synchronized with a global center every once in a while. 2) Each user can retrieve keys as necessary from a server. 3) Each user can build his/her own database independently.
For #1, we need to look at the lesson learned in the beginning of the Internet, with the HOSTS.TXT file. This would soon overwhelm the network, so they created DNS.
For #2, it's cool, except how do we know that Mallory hasn't changed the keys in the server?
For #3, we can't know that in receiving the public key, Mallory hasn't changed it along the way.
So, we come up with a new idea: Public Key Trust Management. There's a couple ways of doing this:
#1: Everyone has to trust a Trent.
#2: There is no Trent; Alice trusts Bob to introduce David, but doesn't trust Carol to introduce David (Alice doesn't think that Carol knows the reasons behind key signatures, and thus does them blindly).
Number 1 is currently used by Verisign and Thawte, embedding their root certificates into the web browsers that everyone uses. These certificates are used to verify the ultimate validity of any public key received.
Number 2 is used by PGP, letting each individual user choose whether and how much to trust any key in the system. (Remember, a key does not come from a user just because it -says- it does.)
Let's use an example: We have a system that requires that Trent be the creator of all certificates that are trusted. (i.e., SSL.) Trent signs the certificates of Alice, Bob, and Carol, after due proof of identity. Frank, not knowing any of them, can obtain their keys and certificates, and since he trusts Trent as well, can trust them.
Let's use an alternate example: We have a system that requires that the user choose who to trust out of all the keys that he has. Alice, Bob, and Carol all know each other and trust each other, for good reason -- they know what's going on. For a new user, like David, he doesn't know who to trust... so he simply signs everything that comes in, and blindly trusts it. One of these keys says it's from Alice, and David needs to talk to Alice, so he uses it. Unfortunately, it's from Mallory, who's trying to understand what it is that Alice and David are talking about. Mallory just goes through and replaces the keys that each user sees on the network for each other, and neither of them are the wiser.
(Yes, these explanations are simplified. I didn't have time or energy to write out the full description of both.)
Both approaches have their downfalls (what if Mallory compromises Trent? What if Mallory compromises the network in the second example?). My personal point of view is kind of like Thawte's... there's room in the PGP Web of Trust for both CAs (Trents) and individuals. In fact, Thawte just announced, a month or two ago, that they were going to provide relatively limited access to their CAs through a 'web of trust' model.
So, trust a CA, but also trust your friends. I like Thawte better than Verisign.:)
> And, after all, isn't protecting our children > the goal of each and every one of us?
Uh, no. I'm not of the opinion that 'protecting the children' is a good idea, enforceable, or even desirable. I can understand the POV of the people who do want to do this. I can accept that people don't believe the way I do.
But, what's 'inappropriate'? What's 'dangerous'? It's not so much the information that's dangerous (for example, I have the information on how to make methamphetamine, which is interesting from a purely scientific viewpoint), but what you do with it (if I pulled out the household equipment and picked up the raw materials and started to dabble in it, I'd likely blow my apartment to bits). 'dangerous' information often leads to less-dangerous (and extremely useful) results.
Another question I have is, "Who decides when someone's mature enough to have access to this information?" I know many, many 18 year olds (and 20 year olds, and 26 year olds) who I wouldn't trust with the methamphetamine recipe, but I know plenty of 12 through 15 year olds who I -would- (mainly because they're interested in chemistry, or applied sciences, and I think they'd look at it to see what could be done, and heed the warnings that it could blow up in their faces).
And sex. (pet peeve coming up) This neo-Western culture we live in in the US has determined that sex is something that shouldn't even be discussed with a kid, much less let them find any information out about. You can find this in some of the self-rating PICS systems in existence -- http://www.safesurf.com/ssplan.htm (SafeSurf) for example. (I like SafeSurf better than the default one that comes with MSIE, btw, but not much.) It rates a 'technical reference' of any sexual theme at level 3 -- above 'subtle innuendo' and 'explicit innuendo'.
I personally think this is pious poppycock.
Sex is openly discussed in other cultures, and their kids are as healthy (if not more so) than the kids in the US.
Slashdot Mirror
Not only this, but if the workstations are members of a domain with domain trust: Server Manager is able to see -all- computers in the domain (any domain connected to the network, actually), and is able to access the Services control panel (if the current login has either Domain Admins group, Administrators group, or the Administrator password for the remote system). Which can just change the startup for the service on the remote system anyway. And let's not forget remote registry editing capability! Change the startup for SMS Client to 0x0010 (I think), and it gets set to start Automatically. There -is- no definitive guide to how Microsoft security interacts in networked environments. PLUS: SMS offers the capability to run commands on the remote system as though they were run locally!!! No need to have 'lockup' and 'reboot' as integral parts of the service, since anything can be run anyway -- and anything can be copied, and anything can be marked executable. Whee. Microsoft, you're gonna have to eat crow on this one. -Winged
Ah, public key management. The bane of public key cryptosystems.
:)
First, some definitions to make my words have more meaning:
Alice, Bob, Carol, David, Elaine, Frank: Persons A through F in a public key cryptosystem world. Assume that all of them have at least one public/private key pair, and that they know not to give out their public keys. Also assume (unless told otherwise) that they are trying to play fair.
Eve: An 'eavesdropper', one who listens to the message traffic, but who can't alter it for any reason. This person is a snoop, just wanting to get information that isn't supposed to be accessible.
Mallory: A 'malicious' user of the system, someone who actively tries to break the system for whatever purpose. He is assumed to be all-powerful (able to change contents of files on public networks, alter bit traffic on networks, and so on), but not all-knowing (he doesn't know the users' secret or private keys).
Trent: A 'trusted authority' who acts like a notary public for the keys the users are using.
Secret key: Used in symmetric cryptosystems, both parties must have this key to encrypt or decrypt.
Private key: One half of a public/private key pair, the half that should NEVER be made common knowledge.
Public key: One half of a public/private key pair, the half that should be made common knowledge so that people can check your signatures, decrypt messages from you, etc.
Certificate: A 'signed statement', like Trent's notarization, saying that a given public key belongs to who it says it does.
And that should do it for the definitions. Now, onto the public key management systems:
There are three different ways that public keys management can be handled.
1) Each user can have a copy of the entire public key database, synchronized with a global center every once in a while.
2) Each user can retrieve keys as necessary from a server.
3) Each user can build his/her own database independently.
For #1, we need to look at the lesson learned in the beginning of the Internet, with the HOSTS.TXT file. This would soon overwhelm the network, so they created DNS.
For #2, it's cool, except how do we know that Mallory hasn't changed the keys in the server?
For #3, we can't know that in receiving the public key, Mallory hasn't changed it along the way.
So, we come up with a new idea: Public Key Trust Management. There's a couple ways of doing this:
#1: Everyone has to trust a Trent.
#2: There is no Trent; Alice trusts Bob to introduce David, but doesn't trust Carol to introduce David (Alice doesn't think that Carol knows the reasons behind key signatures, and thus does them blindly).
Number 1 is currently used by Verisign and Thawte, embedding their root certificates into the web browsers that everyone uses. These certificates are used to verify the ultimate validity of any public key received.
Number 2 is used by PGP, letting each individual user choose whether and how much to trust any key in the system. (Remember, a key does not come from a user just because it -says- it does.)
Let's use an example: We have a system that requires that Trent be the creator of all certificates that are trusted. (i.e., SSL.) Trent signs the certificates of Alice, Bob, and Carol, after due proof of identity. Frank, not knowing any of them, can obtain their keys and certificates, and since he trusts Trent as well, can trust them.
Let's use an alternate example: We have a system that requires that the user choose who to trust out of all the keys that he has. Alice, Bob, and Carol all know each other and trust each other, for good reason -- they know what's going on. For a new user, like David, he doesn't know who to trust... so he simply signs everything that comes in, and blindly trusts it. One of these keys says it's from Alice, and David needs to talk to Alice, so he uses it. Unfortunately, it's from Mallory, who's trying to understand what it is that Alice and David are talking about. Mallory just goes through and replaces the keys that each user sees on the network for each other, and neither of them are the wiser.
(Yes, these explanations are simplified. I didn't have time or energy to write out the full description of both.)
Both approaches have their downfalls (what if Mallory compromises Trent? What if Mallory compromises the network in the second example?). My personal point of view is kind of like Thawte's... there's room in the PGP Web of Trust for both CAs (Trents) and individuals. In fact, Thawte just announced, a month or two ago, that they were going to provide relatively limited access to their CAs through a 'web of trust' model.
So, trust a CA, but also trust your friends. I like Thawte better than Verisign.
-Winged
Considering that code segments are not by default readable on the x86 (if I remember correctly), this might actually be doable.
-Mat
> the goal of each and every one of us?
Uh, no. I'm not of the opinion that 'protecting the children' is a good idea, enforceable, or even desirable. I can understand the POV of the people who do want to do this. I can accept that people don't believe the way I do.
But, what's 'inappropriate'? What's 'dangerous'? It's not so much the information that's dangerous (for example, I have the information on how to make methamphetamine, which is interesting from a purely scientific viewpoint), but what you do with it (if I pulled out the household equipment and picked up the raw materials and started to dabble in it, I'd likely blow my apartment to bits). 'dangerous' information often leads to less-dangerous (and extremely useful) results.
Another question I have is, "Who decides when someone's mature enough to have access to this information?" I know many, many 18 year olds (and 20 year olds, and 26 year olds) who I wouldn't trust with the methamphetamine recipe, but I know plenty of 12 through 15 year olds who I -would- (mainly because they're interested in chemistry, or applied sciences, and I think they'd look at it to see what could be done, and heed the warnings that it could blow up in their faces).
And sex. (pet peeve coming up) This neo-Western culture we live in in the US has determined that sex is something that shouldn't even be discussed with a kid, much less let them find any information out about. You can find this in some of the self-rating PICS systems in existence -- http://www.safesurf.com/ssplan.htm (SafeSurf) for example. (I like SafeSurf better than the default one that comes with MSIE, btw, but not much.) It rates a 'technical reference' of any sexual theme at level 3 -- above 'subtle innuendo' and 'explicit innuendo'.
I personally think this is pious poppycock.
Sex is openly discussed in other cultures, and their kids are as healthy (if not more so) than the kids in the US.
-Mat Butler