We run about twenty systems with RAID storage devices (about half of them fibre channel). I've only had one system go down due to the storage device, ever. I think the power supply on our FC bays failed once or twice, but they have backup PSUs, so it wasn't a problem (hot swap, even!).
Unwise? Yes. But we're talking about standards/conformance/ here. The MSVC compiler correctly compiled a C snippet, and people are fscking complaining about it! (And I got modded "troll" for pointing it out... sheesh. No wonder we're being outsourced to India.)
Second, a compiler screaming bloody murder is a QoI issue. A good ANSI compiler should *compile the code*; a well-implemented compiler should also issue a warning.
Third, it's still in C99. Those guys didn't remove/anything/.
No, you don't. In C, calling an undeclared function implicitly declares it as taking a indeterminate number of arguments and returning an int. Another person who doesn't know what they're talking about... again, please STFU.
How'd that get modded informative? In ANSI C, you don't need the include to use printf. Please STFU, since you obviously don't know what you're talking about.
Open a cmd window as admin, at the prompt do "start explorer". It will bring up a Windows Explorer session with admin privileges. Navigate to Network and Dialup Connections (or any Control Panel) and do your thang.
Also, Task Manager most certainly does display which user owns which process. Go to View|Select Columns and make sure "User Name" is checked.
Heh... I've seen Unix admin books that recommend (in certain, limited circumstances) replacing/sbin/init with a shellscript. How about that for an example of a way to hide a service on Unix?
As for your "(if it's there, you created it" point, have you ever actually had a job?
Do you really think the military would depend on a technology that can be disabled so easily? We're switching to TADIL-J (and TADIL-A where necessary), which is supposedly jam-resistant.
If a service is essential, you need it for some reason. You'd need the same service whether the machine was a Windows machine or a Linux machine. So if you're talking about a flaw in an FTP server, Apache and ProFTPd aren't immune. If you're talking about a flaw in SMB, Samba's not immune. If you're talking about a flaw in AD, NIS+ sure as hell isn't immune.
I'm kind of confused by what your point was, exactly. Would you like to compare the number of critical security patches between, say, Windows XP and Debian 3.0?
It recommends you create a non-admin user, and you have the option of not doing so. Debian's installer does the exact same thing. (Debian probably uses stronger language... I don't recall. But if you're going to quibble about the strength of the recommendation... I mean, come on!)
It depends on the apps you use. When you log in as a regular user, what doesn't work? Figure out exactly what privileges it needs, and go from there. If you have a program with weird requirements, you can create a special user just for it.
For all your admin stuff, you can create shortcuts that always pop-up a "Run as" dialog box. You can even make a shortcut that opens an Explorer window or CLI session as admin, whence you can do anything.
My personal choice is a su'ed cmd.exe. From there, I can just type in the command I want (explorer, mmc, run a program, net..., etc).
By design? I guess the MS guys who put the "Run As" option on the shift-right-click menu for 2K and then later made it an option on the default context menu for XP just missed the memo.
As far as privileges go, there's no difference between the Windows installer and the Debian installer. Both require you to create a root user and then give you the OPTION of creating a non-root account. As both systems are fully functional with privilege separation, that most Windows users choose to run as root while most Linux users choose not to do so is entirely cultural.
I meant hidden in the sense that they're not always in the usual place (the services MMC). The DCOM RPC mapper (think Welchia, etc) needed to be turned off in the DCOM manager, which is only accessible via an obscure command.
If there was a server on a Linux machine that was started in some obscure shellscript instead of the usual init.d (or whatever your system uses) scripts or inetd, I'd describe it as hidden too.
That's not really my experience, though it's a good point. IME, MS hasn't sat on fixing any hole that doesn't require user interaction. If you can point one out, it'd be interesting.
OTOH, MS can just as easily counter with the, "You rely on a bunch of unwashed hippies who have no real obligation to you," argument.
That's a cultural issue, not a technical one. As I said in another post, there are some changes to the way the Windows installer sets things up by default to make privilege separation more convenient. But the fact of the matter is that it's NOT a difference between Unix and Windows anymore.
True. I've run 2K with good privilege separation for a few years with very few problems. At first there were a lot of apps that didn't like it, but as time went by, everything sorted itself out (and the Run As command was quite useful).
It would be nice if MS set it up so that instead of defaulting to making you an admin user, it set up the administrative MMCs to pop up an admin login box.
Bullshit. A secured box is a secured box. If you turn off all non-essential services in Windows and do the same in Linux, keep your users with low privileges etc on both, and keep both systems up-to-date with patches, they're equally secure.
There are only three variables: how secure is the box/by default/, how easy is it to make the box secure, and how easy is it to apply updates.
You're kidding, right? The main/problem/ with Windows is the number of (often hidden) servers that are running by default. UPnP, DCOM, Windows Messenger, etc, etc, etc.
Slashdot Mirror
We run about twenty systems with RAID storage devices (about half of them fibre channel). I've only had one system go down due to the storage device, ever. I think the power supply on our FC bays failed once or twice, but they have backup PSUs, so it wasn't a problem (hot swap, even!).
Honestly, no, I was talking about ISO C, but ANSI C is nearly the same thing (and my post applies equally to it).
Unwise? Yes. But we're talking about standards /conformance/ here. The MSVC compiler correctly compiled a C snippet, and people are fscking complaining about it! (And I got modded "troll" for pointing it out... sheesh. No wonder we're being outsourced to India.)
/anything/.
Second, a compiler screaming bloody murder is a QoI issue. A good ANSI compiler should *compile the code*; a well-implemented compiler should also issue a warning.
Third, it's still in C99. Those guys didn't remove
No, you don't. In C, calling an undeclared function implicitly declares it as taking a indeterminate number of arguments and returning an int. Another person who doesn't know what they're talking about... again, please STFU.
How'd that get modded informative? In ANSI C, you don't need the include to use printf. Please STFU, since you obviously don't know what you're talking about.
Screw long, complex passwords. Use smartcards.
I did it on one of my Win2K machines prior to posting, just to make sure. I dunno what to tell you.
Open a cmd window as admin, at the prompt do "start explorer". It will bring up a Windows Explorer session with admin privileges. Navigate to Network and Dialup Connections (or any Control Panel) and do your thang.
Also, Task Manager most certainly does display which user owns which process. Go to View|Select Columns and make sure "User Name" is checked.
Heh... I've seen Unix admin books that recommend (in certain, limited circumstances) replacing /sbin/init with a shellscript. How about that for an example of a way to hide a service on Unix?
As for your "(if it's there, you created it" point, have you ever actually had a job?
I didn't realize XP does that. In Win2K, the install only creates one or two users: Administrator and optionally one regular user.
I may have to retract my stance that MS doesn't encourage users to run as superuser.
Do you really think the military would depend on a technology that can be disabled so easily? We're switching to TADIL-J (and TADIL-A where necessary), which is supposedly jam-resistant.
Weird, I thought Linux was all about choice. :-}
I don't remember having to do it last time I installed Red Hat, but that was years ago.
If a service is essential, you need it for some reason. You'd need the same service whether the machine was a Windows machine or a Linux machine. So if you're talking about a flaw in an FTP server, Apache and ProFTPd aren't immune. If you're talking about a flaw in SMB, Samba's not immune. If you're talking about a flaw in AD, NIS+ sure as hell isn't immune.
I'm kind of confused by what your point was, exactly. Would you like to compare the number of critical security patches between, say, Windows XP and Debian 3.0?
It recommends you create a non-admin user, and you have the option of not doing so. Debian's installer does the exact same thing. (Debian probably uses stronger language... I don't recall. But if you're going to quibble about the strength of the recommendation... I mean, come on!)
It depends on the apps you use. When you log in as a regular user, what doesn't work? Figure out exactly what privileges it needs, and go from there. If you have a program with weird requirements, you can create a special user just for it.
..., etc).
For all your admin stuff, you can create shortcuts that always pop-up a "Run as" dialog box. You can even make a shortcut that opens an Explorer window or CLI session as admin, whence you can do anything.
My personal choice is a su'ed cmd.exe. From there, I can just type in the command I want (explorer, mmc, run a program, net
By design? I guess the MS guys who put the "Run As" option on the shift-right-click menu for 2K and then later made it an option on the default context menu for XP just missed the memo.
As far as privileges go, there's no difference between the Windows installer and the Debian installer. Both require you to create a root user and then give you the OPTION of creating a non-root account. As both systems are fully functional with privilege separation, that most Windows users choose to run as root while most Linux users choose not to do so is entirely cultural.
I meant hidden in the sense that they're not always in the usual place (the services MMC). The DCOM RPC mapper (think Welchia, etc) needed to be turned off in the DCOM manager, which is only accessible via an obscure command.
If there was a server on a Linux machine that was started in some obscure shellscript instead of the usual init.d (or whatever your system uses) scripts or inetd, I'd describe it as hidden too.
That's not really my experience, though it's a good point. IME, MS hasn't sat on fixing any hole that doesn't require user interaction. If you can point one out, it'd be interesting.
OTOH, MS can just as easily counter with the, "You rely on a bunch of unwashed hippies who have no real obligation to you," argument.
That's a cultural issue, not a technical one. As I said in another post, there are some changes to the way the Windows installer sets things up by default to make privilege separation more convenient. But the fact of the matter is that it's NOT a difference between Unix and Windows anymore.
True. I've run 2K with good privilege separation for a few years with very few problems. At first there were a lot of apps that didn't like it, but as time went by, everything sorted itself out (and the Run As command was quite useful).
It would be nice if MS set it up so that instead of defaulting to making you an admin user, it set up the administrative MMCs to pop up an admin login box.
Bullshit. A secured box is a secured box. If you turn off all non-essential services in Windows and do the same in Linux, keep your users with low privileges etc on both, and keep both systems up-to-date with patches, they're equally secure.
/by default/, how easy is it to make the box secure, and how easy is it to apply updates.
There are only three variables: how secure is the box
No, not really. But there is something to be said about separation of privileges and what-have-you.
You're kidding, right? The main /problem/ with Windows is the number of (often hidden) servers that are running by default. UPnP, DCOM, Windows Messenger, etc, etc, etc.
The act of selling the IPs /is/ evidence of a crime (conspiracy), or at least it would be in the US.