Domain: microsoft.com
Stories and comments across the archive that link to microsoft.com.
Comments · 34,132
-
Free E-Book
You can get the Microsoft® Visual Web Developer(TM) 2005 Express Edition: Build a Web Site Now! e-book free when you register the Express Edition(s).
https://connect.microsoft.com/downloads/downloadDe tails.aspx?siteid=40&downloadid=240 -
Finding VB ExpressIt seems VB Express (http://msdn.microsoft.com/vstudio/express/vb/def
a ult.aspx) is a free (445M) download.VB Express (.img file)
http://go.microsoft.com/fwlink/?linkid=54764VB Express (.iso file)
http://go.microsoft.com/fwlink/?linkid=57033 -
Finding VB ExpressIt seems VB Express (http://msdn.microsoft.com/vstudio/express/vb/def
a ult.aspx) is a free (445M) download.VB Express (.img file)
http://go.microsoft.com/fwlink/?linkid=54764VB Express (.iso file)
http://go.microsoft.com/fwlink/?linkid=57033 -
Finding VB ExpressIt seems VB Express (http://msdn.microsoft.com/vstudio/express/vb/def
a ult.aspx) is a free (445M) download.VB Express (.img file)
http://go.microsoft.com/fwlink/?linkid=54764VB Express (.iso file)
http://go.microsoft.com/fwlink/?linkid=57033 -
Stupid Program, Stupid Movie
Their goal turned out to be the creation of a piece of software later called Fog Creek Copilot, which would help techies fix customers' or relatives' computers by giving them remote access to the ailing machines.
Great idea! Take an idea that already exists, in several variations, and create yet another incompatible implementation. When it fails, you can always fall back on the movie!
Oh well, they were only interns anyways. -
Re:How does it compare to Windows XP Remote Assist
http://www.microsoft.com/windowsxp/using/helpands
u pport/learnmore/remoteassist/viaemail.mspx
Maybe it will be useful in the future.
No need to open ports, either. -
Re:Why such a fancy system?The only thing I've tried on my PC is the Apple Quicktime HD trailer for Cars, which didn't work very well at all on my 3 year old PC, it displayed like 2fps and acted like it wanted to die.
On the XBox 360, you can get a bunch of 720p trailers for free too, those seem to work well. (some game trailers available for download here)
I guess Windows Media 9 also supports HD, and there are some trailers available there too.
OTA HD tuners are available now. CableCard is starting to become available. And there's some heavily-protected stuff on cable/satellite. But once HD-DVD or BluRay takes off, there will be a lot more content floating around. But there's probably some out on BitTorrent already.
-
Re:Why such a fancy system?The only thing I've tried on my PC is the Apple Quicktime HD trailer for Cars, which didn't work very well at all on my 3 year old PC, it displayed like 2fps and acted like it wanted to die.
On the XBox 360, you can get a bunch of 720p trailers for free too, those seem to work well. (some game trailers available for download here)
I guess Windows Media 9 also supports HD, and there are some trailers available there too.
OTA HD tuners are available now. CableCard is starting to become available. And there's some heavily-protected stuff on cable/satellite. But once HD-DVD or BluRay takes off, there will be a lot more content floating around. But there's probably some out on BitTorrent already.
-
Re:Live? What's with Live?
I think MS already has it.
-
Re:Erm....
-
Re:Erm....
-
Re:Or...
I knew someone would turn this into a flamefest about ActiveX.
Allow me to make a technical point on slashdot -- ActiveX is nothing more than an interface standard. It's neither "secure" or "insecure" by itself. As it is used in IE it's no less secure than any other browser plugin mechanism, including those found in Firefox or Safari.
The technology you dislike is not ActiveX -- it's called Internet Component Download. And while it still exists, it's pretty limited in XPSP2, and there's been some rumblings that it will be removed alltogether in Vista. -
ALT+D is a key combo that needs to die.
ALT+ should stick to activating buttons and menus. In other languages, there are menus that should have the accelerator D, and there are more of these examples of these collisions. I'm pretty sure the designers of IE has had plenty of reason to smack themselves in the head for not thinking this through beforehand.
Epiphany for instance refuses to follow the conventions on this one, and while it is a bit annoying the first period of time, I do think they are making the right descision. CTRL+L still works, of course, and in the same smooth way as Firefox. Being consistent and catering to all users of all nationalities are both worthwhile goals IMO. Copying an old mistake from a mostly obsolete dinosaur is not. -
Nature should do their homework
There's actually published work on this (to Nature's credit, this is fairly recent work). This system called Vigilante [1] (incidentally from Microsoft Research) does it all: automatice detection of worm, automatic distribution of signatures, automatic generation of "filters" and protection mechanisms. In the paper, the author's don't use honeypots, but there's nothing in the system that precludes their use.
[1] http://research.microsoft.com/research/pubs/view.a spx?type=Publication&id=1483
Published in this years ACM Symposium on Operating Systems Principles (SOSP) -
Erm....re you dismayed that Microsoft hasn't lifted a finger to improve or enhance IE since it buried Netscape's Navigator browser at the dawn of the century?
I am not an IE zealot (I use FireFox), but this statement isn't 100% accurate. MS did add popup blocking support for IE in SP2. And there are a ton of new features for IE7.
Granted, too little, too late, and way behind FireFox's release/feature schedule (which is why I use FF and not IE), but at least Microsoft is doing something. Proof that competition is a Good Thing.
-
Re:Seems like some people don't understand coding
Yes, it's a design flaw. It's not insurmountable, but does make certain practices unsafe. I don't think that it's unreasonable for programs that are trusted with elevated privileges to be aware of this and protect themselves accordingly. Those programs already have a long list of things they have to be careful about, like not leaving unnecessary ports open, care to avoid buffer overruns, not using shared memory for IPC (unless you're really careful), etc. Not opening windows on the interactive desktop (like it is by default for services) isn't an excessive requirement.
Actually, using a program like jobprc, an you can separate processes with different privileges with jobs and desktops if you want. The extended Software Restriction Policies levels can also do the same thing automatically, on a hash, path or certificate basis. -
why
-
Re:funny department
I guess I had copied a slight misquote.
Here's the original quote:
"Well, Microsoft stepped back and looked at that situation and said that the best thing for us might be to start from scratch: build a new system, focus on having a lot of the great things about Unix, a lot of the great things about Windows, and also being a file-sharing server that would have the same kind of performance that, up until that point, had been unique to Novell's Netware.
And through Windows NT, you can see it throughout the design. In a weak sense, it is a form of Unix. There are so many of the design decisions that have been influenced by that environment. And that's no accident. I mean, we knew that Unix operability would be very important and we knew that the largest body of programmers that we'd want to draw on in building Windows NT applications would certainly come from the Unix base." Source: http://www.microsoft.com/billgates/speeches/indust ry&tech/uexpo.asp -
Re:Not a load of dung, just expensive
Read this. Tested against Blaster, Slammer, and Code Red. It gives specifics of what signitures it generated, how fast they were generated, how fast they were distributed, and how well the infection was contained in their simulated outbreaks. Also includes an analysis of how it would work if the worm tried to DOS the detection system itself.
If you insist on a dead tree copy, well, the printed proceedings are generally only distributed at the conference itself, which is already past, and you can't have mine. Maybe you can buy them from the ACM somehow, since they organize SOSP. I'd assume a link to the PDF posted by the authors would be the most useful way to point you at work which does what you want.
As for moving the boundaries, the story talks about stopping a fast-spreading internet worm. I'm wasn't away that we were discussing something else.
You can detect most other worms when they try to write to the disk to a file they oughtn't (again, the honeypot server is yours so you KNOW where it should be writing, e.g. the log files and nowhere else), or if it executes code that it shouldn't. Since it is on a VM, it can't slip writes past you, because your disk is emulated. If you intercept every instruction fetch (which is what makes this slow), you can verify that the executable bits you are fetching match the ones that you started with. Or use the NX bits. Since I totally "own" the VM, you can only hide by not doing anything. And if you don't do anything, then how do you expect to spread? -
Re:Six-button remote control
look in the bottom right hand corner. it's not where you'd expect a button to be, but then it's easy for MS design to suck.
I still have no idea what you're talking about. Look at this picture and tell me what it says on, below, or next to this magic skin-changing key you're talking about.
I regularly use at least 22 of the buttons on that remote. I could probably do without the number pad and the 'live tv' button if I had to, but the button combinations required to get any functionality out of a 6 button remote are probably similar to trying to get the super ultra mega death combo out of your character in Mortal Kombat. -
Re:Not a load of dung, just expensive
Lord Kelvin, president, Royal Society, 1895 "Heavier-than-air flying machines are impossible."
The difference here is that Lord Kelvin said it before it had been done.
The problem, boiled down to its smallest, is to find inputs to the computer which cause it to emit bad outputs (e.g. cause it to try to spread the worm). We control the honeypot, so we can strictly classify what good outputs are (generally nothing, or some small set of fixed responses)--everything else is therefore bad. Any message to the honeypot, therefore, can be easily classified into causing a bad output or not.
If our signatures are composed of the inputs (in their entirety) which cause bad outputs, there can be no false positives--if that input is fed into the same system, it will spread the worm. Hosts recieving the signature can verify this by testing the signature in a virtual machine. "Gee, I fed it into my machine, and it started spewing traffic all over the place! Guess that really is a worm."
This is less than ideal for polymorphic worms (because you only get one signature), but polymorphic worms are slower than non-polymorphic ones, so they aren't as much of a threat (there are techniques for detecting polymorphic worms but they have non-zero (but quite small) false-positive rates). Also, worms which don't cause the honeypot to output anything for a long time can also slip by with false negatives. But if the worm takes a long time to spread itself, then it is, by definition, NOT a fast-spreading worm, and NOT the target of an automatic immune system.
Most work makes a trade off between a small false positive rate to faster/more powerful detection--here, false positives are measured in the 1 to a billion, or even lower. They also shortcut the detection some--you just need to be running code that wasn't on the machine to start with. Unless your web server is in the habit of accepting code from strangers to run, this is a surefire indication of a bad input.
Of course, these improvements aren't necessary to show that it is possible to have zero-false-positive detection; the scheme I describe above will work. Everything else is tradeoffs to make it faster, more sensitive, etc.
If you don't want to "wade" through lots of work, try just one: Vigilante, Unlike the paper from the story, Vigilante is actually implemented, and has been tested on simulated worm outbreaks using real worms. It also covers the current art of the field. -
Re:The Quick Work-around
Yes, there is actually a patch that has been released to fix this issue with FireFox.
You might want to check it out. -
Re:Oh, Lordy!
NTFS does have hard links.
-
Vigilante
The article in the story doesn't seem to mention existing work in the same area. This approach has already be proposed, evaluated and peer-reviewed in the top networking conference (SIGCOMM'04) [1] and the top Operating System's conference (SOSP'05) [2]. The existing approach was proposed by Microsoft Research and is called Vigilante.
They find that it is possible to quickly detect worms automatically, construct automatic filters for just the worm and not benign traffic, and distribute it quickly to vulnerable hosts in a secure, non-forgeable way.
[1] http://portal.acm.org/citation.cfm?id=1095809.1095 824
[2] http://research.microsoft.com/research/pubs/view.a spx?type=Publication&id=1483 -
This isn't a very good paper.
I didn't know that Nature was such a high end CS publication. At SOSP this year Vigilante (http://research.microsoft.com/~manuelc/MS/Vigila
n teSOSP.pdf) was presented--a much more complete paper in a more salient venue.
The citations list at the end of the Nature paper also is missing a large body of relevant work. Check the citations list of the Vigilante paper for details--50 references most of which are missing from the Nature pub. Also, the publications the Nature paper cites are mixed--some are good (like http://www.icsi.berkeley.edu/~nweaver/containment/ ), but I don't think the editors of "Physical Review Letters" (a physics journal) are really up to speed on the latest in computer security research. Indeed, most of the works they cite are either from physics journals, Nature, or Science.
The analysis is quite math heavy, and makes some unrealistic assumptions (i.e. worms only spread to their neighbors). In the end, they "show" that it is theoretically possible to stop worms with a side-channel network. Vigilante, on the other hand, has an implementation of a vaccination system, and simulation results run against Blaster, Slammer, and Code Red. Now, which is more convincing to you? -
Vigilante
Microsoft and University of Cambridge have been working on the same kind of thing for a while. There was a paper at the SOSP 2005 conference.
-
Re:Seems like some people don't understand coding
Wait. Did I just say message passing? Why, that would imply that anyone can pass messages to the background process. In fact, thanks to design flaws I don't want to get into right now, it is possible to any program, running under that user, to create a window handle and pass it in using a certain type of message, and get the privs of that program. Aka, superuser. This cannot be fixed any and have Windows remain backwards compatible.
Windows are always created in the context of a desktop object. Desktop objects have been available since NT 3.51. Every GUI thread has exactly one associated desktop object, and it can only create and interact with windows on that desktop. Since desktop objects have a security descriptor, the calling process must have the proper permission to open and interact with a desktop. Privileged services can open all the windows they want, as long as the desktops they do so in are not accessible from unprivileged users. By default, the service control manager automatically creates a non-interactive window station (the container for desktops) for every service that tries to create windows, inaccessible to unprivileged users. Some ignorant developers are ignoring the stated best practices and are accessing the user's desktop from privileged process. This isn't Microsoft's fault; they can't control what other people do with their computers.
The only way to guard against this is to make sure that all programs that might run under a different user never make a window. Ever. Even Microsoft has been guilty of doing this once in a while, although they have cleaned up their act and a default install of XP has no such windows.
Another way to protect against shatter attacks is to create the untrusted processes in a job object that denies access to window handles outside the job. The untrusted processes can access each other's windows, but can't access the window handles of processes that aren't in the job. No destination = no malicious messages. -
Re:Seems like some people don't understand coding
Wait. Did I just say message passing? Why, that would imply that anyone can pass messages to the background process. In fact, thanks to design flaws I don't want to get into right now, it is possible to any program, running under that user, to create a window handle and pass it in using a certain type of message, and get the privs of that program. Aka, superuser. This cannot be fixed any and have Windows remain backwards compatible.
Windows are always created in the context of a desktop object. Desktop objects have been available since NT 3.51. Every GUI thread has exactly one associated desktop object, and it can only create and interact with windows on that desktop. Since desktop objects have a security descriptor, the calling process must have the proper permission to open and interact with a desktop. Privileged services can open all the windows they want, as long as the desktops they do so in are not accessible from unprivileged users. By default, the service control manager automatically creates a non-interactive window station (the container for desktops) for every service that tries to create windows, inaccessible to unprivileged users. Some ignorant developers are ignoring the stated best practices and are accessing the user's desktop from privileged process. This isn't Microsoft's fault; they can't control what other people do with their computers.
The only way to guard against this is to make sure that all programs that might run under a different user never make a window. Ever. Even Microsoft has been guilty of doing this once in a while, although they have cleaned up their act and a default install of XP has no such windows.
Another way to protect against shatter attacks is to create the untrusted processes in a job object that denies access to window handles outside the job. The untrusted processes can access each other's windows, but can't access the window handles of processes that aren't in the job. No destination = no malicious messages. -
Re:Seems like some people don't understand coding
Wait. Did I just say message passing? Why, that would imply that anyone can pass messages to the background process. In fact, thanks to design flaws I don't want to get into right now, it is possible to any program, running under that user, to create a window handle and pass it in using a certain type of message, and get the privs of that program. Aka, superuser. This cannot be fixed any and have Windows remain backwards compatible.
Windows are always created in the context of a desktop object. Desktop objects have been available since NT 3.51. Every GUI thread has exactly one associated desktop object, and it can only create and interact with windows on that desktop. Since desktop objects have a security descriptor, the calling process must have the proper permission to open and interact with a desktop. Privileged services can open all the windows they want, as long as the desktops they do so in are not accessible from unprivileged users. By default, the service control manager automatically creates a non-interactive window station (the container for desktops) for every service that tries to create windows, inaccessible to unprivileged users. Some ignorant developers are ignoring the stated best practices and are accessing the user's desktop from privileged process. This isn't Microsoft's fault; they can't control what other people do with their computers.
The only way to guard against this is to make sure that all programs that might run under a different user never make a window. Ever. Even Microsoft has been guilty of doing this once in a while, although they have cleaned up their act and a default install of XP has no such windows.
Another way to protect against shatter attacks is to create the untrusted processes in a job object that denies access to window handles outside the job. The untrusted processes can access each other's windows, but can't access the window handles of processes that aren't in the job. No destination = no malicious messages. -
Re:Seems like some people don't understand coding
Wait. Did I just say message passing? Why, that would imply that anyone can pass messages to the background process. In fact, thanks to design flaws I don't want to get into right now, it is possible to any program, running under that user, to create a window handle and pass it in using a certain type of message, and get the privs of that program. Aka, superuser. This cannot be fixed any and have Windows remain backwards compatible.
Windows are always created in the context of a desktop object. Desktop objects have been available since NT 3.51. Every GUI thread has exactly one associated desktop object, and it can only create and interact with windows on that desktop. Since desktop objects have a security descriptor, the calling process must have the proper permission to open and interact with a desktop. Privileged services can open all the windows they want, as long as the desktops they do so in are not accessible from unprivileged users. By default, the service control manager automatically creates a non-interactive window station (the container for desktops) for every service that tries to create windows, inaccessible to unprivileged users. Some ignorant developers are ignoring the stated best practices and are accessing the user's desktop from privileged process. This isn't Microsoft's fault; they can't control what other people do with their computers.
The only way to guard against this is to make sure that all programs that might run under a different user never make a window. Ever. Even Microsoft has been guilty of doing this once in a while, although they have cleaned up their act and a default install of XP has no such windows.
Another way to protect against shatter attacks is to create the untrusted processes in a job object that denies access to window handles outside the job. The untrusted processes can access each other's windows, but can't access the window handles of processes that aren't in the job. No destination = no malicious messages. -
Re:Seems like some people don't understand coding
Wait. Did I just say message passing? Why, that would imply that anyone can pass messages to the background process. In fact, thanks to design flaws I don't want to get into right now, it is possible to any program, running under that user, to create a window handle and pass it in using a certain type of message, and get the privs of that program. Aka, superuser. This cannot be fixed any and have Windows remain backwards compatible.
Windows are always created in the context of a desktop object. Desktop objects have been available since NT 3.51. Every GUI thread has exactly one associated desktop object, and it can only create and interact with windows on that desktop. Since desktop objects have a security descriptor, the calling process must have the proper permission to open and interact with a desktop. Privileged services can open all the windows they want, as long as the desktops they do so in are not accessible from unprivileged users. By default, the service control manager automatically creates a non-interactive window station (the container for desktops) for every service that tries to create windows, inaccessible to unprivileged users. Some ignorant developers are ignoring the stated best practices and are accessing the user's desktop from privileged process. This isn't Microsoft's fault; they can't control what other people do with their computers.
The only way to guard against this is to make sure that all programs that might run under a different user never make a window. Ever. Even Microsoft has been guilty of doing this once in a while, although they have cleaned up their act and a default install of XP has no such windows.
Another way to protect against shatter attacks is to create the untrusted processes in a job object that denies access to window handles outside the job. The untrusted processes can access each other's windows, but can't access the window handles of processes that aren't in the job. No destination = no malicious messages. -
Re:Mod parent up!
When the term [multi-user] was developed, it meant the capability of the OS/System to serve multiple actual people simultaneously.
Um, I can serve as many users as I want if they connect using SSH or X-Windows from any version of Windows NT, and they will each have their own environment, secure from the others. The backend support for using the Win32 GUI (desktop, window station objects) has existed since NT 3.51 (although it required Citrix Winframe for frontend and protocol), and Microsoft Terminal Server (no third-party components required) has been available since NT4 TSE. The Win32 GUI is not required for a multiuser system; in fact, many UNIX and IBM iSeries systems are considered fully multiuser using only text mode connections.
The most important part about being multiuser is the security that protects users from each other when simultaneously executing code on the same machine. NT has supported this since its first release.Create a shortcut to the "Add/Remove Programs" control panel applet. Make sure you do this as an unprivileged user. Right-click and click on the "RunAs"... oh wait, it's not there. Hmm... Seems like you have to login with an Administrative account to "Add/Remove" programs from your system. That is an important, yet missing feature of the "RunAs" command. (I thought you knew Windows.)
You can run the control panel (and so add/remove) as a different user, although it does take some extra work. This is a known issue and it does suck. Normally, when you launch Explorer (control panel is part of explorer), it just sends a signal to the existing explorer process to open a new window and exits. This behavior dates back to Windows 95 on 4MB of memory when creating a new process would have wasted memory. I think this behavior should have gone away a while ago, but in the meantime launch Internet Explorer as a different user and browse to the control panel from there (type in C: in the address bar, enable folder view and open the control panel on the left)
I believe that "RunAs" only works for the initial application being called, it's not capable of spawning off sub-processes under the elevated privileges the application inherits from the initial "RunAs" activation.
No, in Win32, child processes always inherit the security context (token) of the parent process unless the parent has AssignPrimaryToken privilege (only SYSTEM has it by default) or the child will be created with a restricted version of the parent's token. See CreateProcessAsUser.
On modern UNIX servers/workstations, very few processes that could be whacked and overtaken are running as root. The best practices security models demand that dummy accounts be created for processes that accept external input so that if one of those is compromised, at best, the low or unskilled cracker will end up with a useless sandbox that won't even play nice.
Microsoft's best practices since NT 3.51 stipulate that privileged services should never, ever access the interactive desktop for just this reason. This doesn't stop ignorant third party application developers from ignoring that. You're supposed to create a client program that runs in the context of the logged-on user that communicates with the sever using IPC like a named pipe. There's even a flag you can set to disable all interactive services. It's not set by default because it would break too many crappy third party programs.
No, but IE does have some components that have access beyond the level required for basic User Space interaction. These components are the weakness inherent in IE and why, even if running IE as an unprivil
-
Re:Mod parent up!
When the term [multi-user] was developed, it meant the capability of the OS/System to serve multiple actual people simultaneously.
Um, I can serve as many users as I want if they connect using SSH or X-Windows from any version of Windows NT, and they will each have their own environment, secure from the others. The backend support for using the Win32 GUI (desktop, window station objects) has existed since NT 3.51 (although it required Citrix Winframe for frontend and protocol), and Microsoft Terminal Server (no third-party components required) has been available since NT4 TSE. The Win32 GUI is not required for a multiuser system; in fact, many UNIX and IBM iSeries systems are considered fully multiuser using only text mode connections.
The most important part about being multiuser is the security that protects users from each other when simultaneously executing code on the same machine. NT has supported this since its first release.Create a shortcut to the "Add/Remove Programs" control panel applet. Make sure you do this as an unprivileged user. Right-click and click on the "RunAs"... oh wait, it's not there. Hmm... Seems like you have to login with an Administrative account to "Add/Remove" programs from your system. That is an important, yet missing feature of the "RunAs" command. (I thought you knew Windows.)
You can run the control panel (and so add/remove) as a different user, although it does take some extra work. This is a known issue and it does suck. Normally, when you launch Explorer (control panel is part of explorer), it just sends a signal to the existing explorer process to open a new window and exits. This behavior dates back to Windows 95 on 4MB of memory when creating a new process would have wasted memory. I think this behavior should have gone away a while ago, but in the meantime launch Internet Explorer as a different user and browse to the control panel from there (type in C: in the address bar, enable folder view and open the control panel on the left)
I believe that "RunAs" only works for the initial application being called, it's not capable of spawning off sub-processes under the elevated privileges the application inherits from the initial "RunAs" activation.
No, in Win32, child processes always inherit the security context (token) of the parent process unless the parent has AssignPrimaryToken privilege (only SYSTEM has it by default) or the child will be created with a restricted version of the parent's token. See CreateProcessAsUser.
On modern UNIX servers/workstations, very few processes that could be whacked and overtaken are running as root. The best practices security models demand that dummy accounts be created for processes that accept external input so that if one of those is compromised, at best, the low or unskilled cracker will end up with a useless sandbox that won't even play nice.
Microsoft's best practices since NT 3.51 stipulate that privileged services should never, ever access the interactive desktop for just this reason. This doesn't stop ignorant third party application developers from ignoring that. You're supposed to create a client program that runs in the context of the logged-on user that communicates with the sever using IPC like a named pipe. There's even a flag you can set to disable all interactive services. It's not set by default because it would break too many crappy third party programs.
No, but IE does have some components that have access beyond the level required for basic User Space interaction. These components are the weakness inherent in IE and why, even if running IE as an unprivil
-
Re:Mod parent up!
When the term [multi-user] was developed, it meant the capability of the OS/System to serve multiple actual people simultaneously.
Um, I can serve as many users as I want if they connect using SSH or X-Windows from any version of Windows NT, and they will each have their own environment, secure from the others. The backend support for using the Win32 GUI (desktop, window station objects) has existed since NT 3.51 (although it required Citrix Winframe for frontend and protocol), and Microsoft Terminal Server (no third-party components required) has been available since NT4 TSE. The Win32 GUI is not required for a multiuser system; in fact, many UNIX and IBM iSeries systems are considered fully multiuser using only text mode connections.
The most important part about being multiuser is the security that protects users from each other when simultaneously executing code on the same machine. NT has supported this since its first release.Create a shortcut to the "Add/Remove Programs" control panel applet. Make sure you do this as an unprivileged user. Right-click and click on the "RunAs"... oh wait, it's not there. Hmm... Seems like you have to login with an Administrative account to "Add/Remove" programs from your system. That is an important, yet missing feature of the "RunAs" command. (I thought you knew Windows.)
You can run the control panel (and so add/remove) as a different user, although it does take some extra work. This is a known issue and it does suck. Normally, when you launch Explorer (control panel is part of explorer), it just sends a signal to the existing explorer process to open a new window and exits. This behavior dates back to Windows 95 on 4MB of memory when creating a new process would have wasted memory. I think this behavior should have gone away a while ago, but in the meantime launch Internet Explorer as a different user and browse to the control panel from there (type in C: in the address bar, enable folder view and open the control panel on the left)
I believe that "RunAs" only works for the initial application being called, it's not capable of spawning off sub-processes under the elevated privileges the application inherits from the initial "RunAs" activation.
No, in Win32, child processes always inherit the security context (token) of the parent process unless the parent has AssignPrimaryToken privilege (only SYSTEM has it by default) or the child will be created with a restricted version of the parent's token. See CreateProcessAsUser.
On modern UNIX servers/workstations, very few processes that could be whacked and overtaken are running as root. The best practices security models demand that dummy accounts be created for processes that accept external input so that if one of those is compromised, at best, the low or unskilled cracker will end up with a useless sandbox that won't even play nice.
Microsoft's best practices since NT 3.51 stipulate that privileged services should never, ever access the interactive desktop for just this reason. This doesn't stop ignorant third party application developers from ignoring that. You're supposed to create a client program that runs in the context of the logged-on user that communicates with the sever using IPC like a named pipe. There's even a flag you can set to disable all interactive services. It's not set by default because it would break too many crappy third party programs.
No, but IE does have some components that have access beyond the level required for basic User Space interaction. These components are the weakness inherent in IE and why, even if running IE as an unprivil
-
Re:Doing some more searching....
Windows NT 3.1 was released in 1993. It had ACLs the same as NT 4.0. That page is wrong. See SetKernelObjectSecurity, a function that sets a security descriptor for a kernel object, including ACL, supported since NT 3.1.
-
Re:Enough Updaters?
Think there are enough updaters out there? I mean, OS X does this with one updater, and you just pick the relevant updates. It seems like that would be better. That way there is no need to access like 5 updaters, you can just use one.
While that is a lot of updaters, there is a reason for it (in part because they're not all updaters):
- Microsoft Update looks like a replacement for Windows Update. It has updates for Microsoft products beyond Windows (like Office).
- You already know what Windows Update is.
- Microsoft Windows Server Update Services is a way for you to run your own Windows Update. This is good for enterprises that want to validate updates before pushing them to their desktops.
- Microsoft Software Installer (also know as MSI) is Microsoft's installation packaging technology. This is not an update service.
- Microsoft Systems Management Server (uses the overloaded SMS abbreviation) is system management software. One of its features is the ability to push updates to client machines. This is a push approach, where the other update services are pull.
When you break it down, you've really got three update services (down from four, with Microsoft Update taking the place of both Windows Update and Office Update), and only one of those is something an average user needs to know about. The other two are targetted squarely at enterprise customers, and allow them to control their own environment rather than relying on Microsoft's update servers.
-
Re:Enough Updaters?
Think there are enough updaters out there? I mean, OS X does this with one updater, and you just pick the relevant updates. It seems like that would be better. That way there is no need to access like 5 updaters, you can just use one.
While that is a lot of updaters, there is a reason for it (in part because they're not all updaters):
- Microsoft Update looks like a replacement for Windows Update. It has updates for Microsoft products beyond Windows (like Office).
- You already know what Windows Update is.
- Microsoft Windows Server Update Services is a way for you to run your own Windows Update. This is good for enterprises that want to validate updates before pushing them to their desktops.
- Microsoft Software Installer (also know as MSI) is Microsoft's installation packaging technology. This is not an update service.
- Microsoft Systems Management Server (uses the overloaded SMS abbreviation) is system management software. One of its features is the ability to push updates to client machines. This is a push approach, where the other update services are pull.
When you break it down, you've really got three update services (down from four, with Microsoft Update taking the place of both Windows Update and Office Update), and only one of those is something an average user needs to know about. The other two are targetted squarely at enterprise customers, and allow them to control their own environment rather than relying on Microsoft's update servers.
-
Re:Enough Updaters?
Think there are enough updaters out there? I mean, OS X does this with one updater, and you just pick the relevant updates. It seems like that would be better. That way there is no need to access like 5 updaters, you can just use one.
While that is a lot of updaters, there is a reason for it (in part because they're not all updaters):
- Microsoft Update looks like a replacement for Windows Update. It has updates for Microsoft products beyond Windows (like Office).
- You already know what Windows Update is.
- Microsoft Windows Server Update Services is a way for you to run your own Windows Update. This is good for enterprises that want to validate updates before pushing them to their desktops.
- Microsoft Software Installer (also know as MSI) is Microsoft's installation packaging technology. This is not an update service.
- Microsoft Systems Management Server (uses the overloaded SMS abbreviation) is system management software. One of its features is the ability to push updates to client machines. This is a push approach, where the other update services are pull.
When you break it down, you've really got three update services (down from four, with Microsoft Update taking the place of both Windows Update and Office Update), and only one of those is something an average user needs to know about. The other two are targetted squarely at enterprise customers, and allow them to control their own environment rather than relying on Microsoft's update servers.
-
Re:Enough Updaters?
Think there are enough updaters out there? I mean, OS X does this with one updater, and you just pick the relevant updates. It seems like that would be better. That way there is no need to access like 5 updaters, you can just use one.
While that is a lot of updaters, there is a reason for it (in part because they're not all updaters):
- Microsoft Update looks like a replacement for Windows Update. It has updates for Microsoft products beyond Windows (like Office).
- You already know what Windows Update is.
- Microsoft Windows Server Update Services is a way for you to run your own Windows Update. This is good for enterprises that want to validate updates before pushing them to their desktops.
- Microsoft Software Installer (also know as MSI) is Microsoft's installation packaging technology. This is not an update service.
- Microsoft Systems Management Server (uses the overloaded SMS abbreviation) is system management software. One of its features is the ability to push updates to client machines. This is a push approach, where the other update services are pull.
When you break it down, you've really got three update services (down from four, with Microsoft Update taking the place of both Windows Update and Office Update), and only one of those is something an average user needs to know about. The other two are targetted squarely at enterprise customers, and allow them to control their own environment rather than relying on Microsoft's update servers.
-
Doing some more searching....
HP-UX had ACLs back in 1992.
See This
At the same time. Windows didn't get ACLs until 1996 with the release of Windows NT 4.0, see below.
Windows ACL -
Re:good idea, but impractical
Movies have one. Television shows have one. Song lyrics have one. Games have one.
And web sites have one. Prior to ICRA, there was RSACi. It's been around for quite a while, so IE supports it (IE supporting something, a shock, I know). I'm not sure if any other browsers directly support it, though. -
Re:Wow, it doesn't even work in IE.
The OneCare Safety Center thingy won't run on IE 7 beta, either. lol.
On a slightly different tangent: From the Live Jobs site:
Do you want to be at the forefront of Microsoft's effort to beat Google, Apple & Yahoo at the same time? Do you want to take up the challenge of converting...
THEY ADMIT IT! -
Re:Control of the integrated platform
Java platform is more open source than MS.Net. You can download the source code for Java, and depending on what you want to do, have various options. Where is the source code for MS.Net platform?
-
Re:OK, so we'll open Java
Sun has control of internet apps/coding. ActiveX/Visual Basic can't really compete.
ahhhh.......huh? OK lets ignore PHP, Perl, Ruby, etc and go to the heart of it (ActiveX/Visual Basic). Have you heard of this (.NET 1.0) , this (.NET 1.1), or this (.NET 2.0)?
I'm not going to sit here and make pointless arguments about better/worse, but I don't think ActiveX/VB is even supported anymore. Wasn't it's final version about 6 years ago? Its not quite as bad as "Sun has control of internet apps/coding. COBOL can't really compete", but I still find it funny ;-) -
Re:OK, so we'll open Java
Sun has control of internet apps/coding. ActiveX/Visual Basic can't really compete.
ahhhh.......huh? OK lets ignore PHP, Perl, Ruby, etc and go to the heart of it (ActiveX/Visual Basic). Have you heard of this (.NET 1.0) , this (.NET 1.1), or this (.NET 2.0)?
I'm not going to sit here and make pointless arguments about better/worse, but I don't think ActiveX/VB is even supported anymore. Wasn't it's final version about 6 years ago? Its not quite as bad as "Sun has control of internet apps/coding. COBOL can't really compete", but I still find it funny ;-) -
Re:OK, so we'll open Java
Sun has control of internet apps/coding. ActiveX/Visual Basic can't really compete.
ahhhh.......huh? OK lets ignore PHP, Perl, Ruby, etc and go to the heart of it (ActiveX/Visual Basic). Have you heard of this (.NET 1.0) , this (.NET 1.1), or this (.NET 2.0)?
I'm not going to sit here and make pointless arguments about better/worse, but I don't think ActiveX/VB is even supported anymore. Wasn't it's final version about 6 years ago? Its not quite as bad as "Sun has control of internet apps/coding. COBOL can't really compete", but I still find it funny ;-) -
Re:Ubuntu?
Exchange 2003 comes with Outlook web access for all your emailing needs. They say it requires a compatible browser, so, perhaps someone else can say if it needs Internet Exploder, or if its happy with Firefox Operat et. al
-
Re:but what powers it?
way over 99% of all executable attachments are malicious
nice stat - what ass did you pull it out of
There is a very small, largely theoretical problem with non-executable content
Do you call this theoretical?
http://www.microsoft.com/technet/security/bulletin /MS05-053.mspx -
Re:That's just great.
While we're at it, why don't we just sell the internet to Microsoft and be done with it?
Too late -
Re:It's all about "cute" data structures