Seriously, I've never gone googling to track things down. I know what I know from writing code and working with/on Windows, nothing more. I haven't gone looking for "proof" of what I've learned from my own code and experiences - what would be the point for me ?
"Of _course_ there is the concept of the local super user, there -has- to be on ANY OS. Whoopee!"
Your latest quote, with this:
" Windows does not have root in the same sense Unix does."
Which was your initial statement I took great issue with.
Your assignment (should you choose to accept it:-) is to re-read these two and try and reconcile your argument. I may be arrogant and senile, but I'm *very* consistent:-).
"Well, if they really are *lying* and you can prove it, if I'm not mistaken there should be laws they can be prosecuted under."
Oh don't be ridiculous ! What, you think every single thing a manufacturer says about their product has to be true or they're prosecuted ? Wait a minute, you quoted textbooks from the University of Queensland. You're a student aren't you. That explains a lot about your simple view of the world and silly statements like that.
I stand by my "willfull ignorance" comment. You are willfully ignorant. There are no books that specificaly state "these facts Microsoft claims about their security model are lies". Why would anyone bother to publish such ? Just do some basic research to learn how things work. Don't just regurgitate OS textbooks at me. You're supposed to be at University to learn how to learn. This is a wonderful opportunity for you.
No, not everything out there disagrees with what I say, only the text from Microsoft, and that written by authors who, like you, are just repeating what Microsoft tells then without actually writing code to *test* these claims.
They're lies. For example, the one that claims that even an Administrator cannot change ownership of a file from one user to another user without taking ownership first. Utter lies. Here's a hint, how do you think a restore from a backup can do this ?
You see, you don't code, you just read the propaganda and you're ignorant. You just believe what you're told. You don't have the skill to test it yourself, so you believe it when Microsoft tells you everything is fine, Windows is secure (if only people would apply those damn patches), and Linux has more security problems than Windows because Windows has a "secure design".
I suppose it's not your fault, but I hate willfull ignorance. If Windows were such a secure design, and there's no such thing as root why do you think there are so many viruses/worms that take over complete control of a machine ?
You remind me of the poor users who, in the early 90's, I ran into patiently waiting for "the Windows NT server to reboot". When I asked them why they weren't outraged by such poor service they replied "but that's what servers do !".
I have news for you, Microsoft *lies*. They lie to promote their own products, and they have convinced the gullable like you that mediocracy is acceptable in both design and implementation. Their security design is no different from UNIX. The reason you don't know that is because you're reading the wrong books.
I was amazed to see similar errors being made in O'Reillys recent book on secure code, in a discussion of the Windows security model. People don't bother to test, they just *assume*.
I don't assume. I have made my living writing code that *checks*. I can't assume what Microsoft says that Windows does is true, I have to interoperate on the wire. I actually have to write code that knows what Windows *does*. Go away and learn something.
"You are making a very bold statement claiming every piece of literature describing Windows NT's architecture is lying."
Oh I see. Now your ignorance makes sense. You're someone who doesn't program for Windows or really understand its security model.
In other words, you just read the Microsoft adverts and documentation, but you've never written security code on Windows. Go away and do so, learn something, then come back.
"I'm sure when there's a CIFS bug you're quick to point out that this doesn't reflect badly on Windows"
When there's a CIFS implementation bug in Windows (and remember we're the ones who have usually found it and reported it to Microsoft) it reflects badly on the CIFS server design in Windows (one multi-threaded mess, embedded in the kernel that can bring down the system if it crashes), not the CIFS protocol itself. This is the Windows "low level architecture" you praise so much. A CIFS server in the kernel... insanity !
The CIFS protocol has other problems, one of them being it's too complicated to implement in a provably secure mannor. Ask Microsoft why they don't serve CIFS from ftp.microsoft.com any more. We were never stupid enough to export CIFS from ftp.samba.org. We don't consider CIFS an internet-safe protocol.
"The Windows low level architecture is more powerful, you have more control over _everything_. "
This is untrue, that's what I'm trying to get you to understand.
In Windows, you have "root" and "not root", just like UNIX. If you're root, the OS puts a lot of API barriers in your way that you have to call through in order to add privillages etc., but there's still nothing you can't do locally.
As for complaining about RPC holes, I don't think Windows has much to be proud of here. DCE/RPC is overly complicated for what it does. ONCE/RPC is a much simpler design, and even it had some implementation security problems.
But even they are *nothing* compared to the pit of hell that are the implementation security problems in Windows RPC. See your local virus/worm vendor for details.
Windows has root in *exactly* the same sense that UNIX does. Do you think Administrator or LOCALSYSTEM on a box can't do anything root can ? Change ownership of files to an arbitrary SID (that's a lie in the Microsoft docs, claiming that can't be done, I wrote a Win32 program to do just that about 11 years ago:-). They *are* root. No, difference.
What you are complaining about is NFS, not UNIX.
Stop comparing *one* of the remote file system protocols in the UNIX world with UNIX itself. And stop claiming that Windows is architectured any differently. You're simply repeating Microsoft propaganda, and people who know better will point out you're lying. You're lying btw.
If you think Windows doesn't have root, you're a fool. Worse, an ignorant fool who propagates Microsoft propaganda as truth.
As for global access to network file systems, that's a NFS flaw, not a UNIX one. Use a more secure remote file protocol, like... gosh - how about *secure NFS* for one !
He didn't write the code with that flaw in it, I did.
So did you get exploited by this flaw ? Did you lose data or get compromised ? Do you have a legitimate complaint, or are you carping anonymously about "communist collective's" because you don't know how to code yourself, and you fear them ?
The psychology behind comments like this is interesting to me, I always wonder if you're the same kind of people who "key" expensive cars because you don't own one ? Did you ever write software yourself ? Do you know how ?
As I recall it breaks explorer, when deleting a tree of directories. I'd have to check the old samba-bugs account to be sure. I didn't know exporer was a 16 bit app:-).
This is pretty obviously a benchmark special, not run in production. I recognise things like that, having done a few of them myself:-).
I don't deal with the design documents, I deal in the protocol bits that the redirector actually emits. And I had to fix this in Samba as not mapping correctly back from 8.3 to long filenames caused applications to break (I think it was the W2K explorer shell, can't remember without going back into the old samba-bugs mail). This is a *required* feature.
I love this philosophy of "well the design docs say it doesn't do that so obviously it doesn't".
The design docs say that ChangeNotify should work with non NTSTATUS error code returns, but it doesn't (and I've *seen* those design docs) !
The design docs don't mention that you can't return ACLs on files unless you return unicode paths for a qfileinfo request on ".", but that's true also.
I suggest that you stop reading the design docs and look at the code.
"And the 8.3 fix isn't likely to break that many current apps. It certainly won't break any apps with a Win95 or greater logo, since the logo requirements for Win9x require that they support non 8.3 files."
Not true. You don't know anything about how the Windows redirector works, obviously. It's not just old W9x apps that use 8.3 filenames. The protocol demands that you can open a create a file with a long name, qfileinfo to get the short (8.3) name, then delete it with the 8.3 name.
The W2K redirector *DOES THIS*.
Don't make uninformed comments when you don't know the details.
"A much better test would have been to let you in to tweak the Samba/Linux server to the best of your abilities, and have the Microsoft rep tweak the NT server to the best of their abilities (allowing each of you to look over the others shoulders to ensure neither side is cheating) and THEN run the numbers."
No, I disagree, I think that would be a terrible test. No one will run that way in production. The cheats and tweaks you can do for netbench are *NOT* what you want in a production system. And we would have to cheat to get good numbers, just in case *they* were cheating to get good numbers (8.3 fix mentioned above). This way lies madness, and no use to anyone.
The best kind of test is the one the vunet people did. Just stick the damn thing on server hardware and run it without any tuning on either side.
> I haven't looked into Samba 3 yet, I have several Win2k > domains, most of them in native mode. I'm interested to see > how exactly a Samba 3 box would fit in a native mode domain.
It just works. That was one of the goals we had to hit before release.
> MS said that they improved file serving so it was "faster > than the competition", which means it's as fast as Samba
No - it means they *said* it was as fast as Samba. Why do you believe that remark and not the vunet one ?
They took some extreme liberties in that benchmark, see my earlier comment for details.
I don't know which is faster, W2K3 or Samba. But I know I'd trust a benchmark done by people who just put the software onto a box and ran it more than a benchmark where I tweaked Samba and the Linux box or one where Microsoft tweaked the W2K3 box (which is the one you're referring to).
Real world use is what counts - how fast does it run in *your* set up. Not how fast I or they can make it run in some lab.
The most damaging thing about the above link is that they disabled 8.3 filename generation on the W2K3 server. In a production environment this WILL BREAK APPLICATIONS !
I discussed this with tridge, and his humorous comment was that if they were bending the rules this much we could just set the server to discard the incoming data (as netbench never actually reads back the data it writes:-), this would be about the same level of cheating:-).
I didn't have anything to do with the vunet tests. But from what the article says, they didn't do any tweaking on the platforms. Which do you think is more valid in a real environment - tuning to the amount given in the Microsoft report, or just putting the software on the box and running it, like the vunet report ?
I would hope that given access to such a netbench test and being allowed to tune Samba and Linux to the extent that Microsoft did I would be able to beat W2K3 in such a test (opinion only, I haven't done such a test).
Known bug - we intend to fix this for 3.0.1. We intend to be able to export the Samba smbd keytab entry in the next release (this is a request I've had inside HP as well). Sorry for the problem you had.
I wouldn't do it. And I write lots of the Samba code:-). The protocol is just too complex to be sure any implementation is safe.
Hopefully that should tell you something. It should also tell you why we don't want it in the Linux kernel. Microsoft put it in their kernel - I think that's a mistake.
No, they never did this. Oplocks are problematic in that Windows boxes tend not to respond to oplock break requests if there are *any* network problems. Most people have cheap switches/hubs etc. For instance on my home network I can only reliably ssh transfer a 100mb file over one of my switches (the gigabit one), the 100Mbit switch will consistantly corrupt the tcp stream causing ssh to abort.
oplocks need *reliable* networking hardware.
Jeremy Allison, Samba Team.
Re:Does this ver. solve the WinXP security "featur
on
Samba 3.0.0 Released
·
· Score: 3, Informative
It's probably the Web sharing service. Turn off the client side on the XP box. It tries to contact a port on the Samba server that isn't open and times out. Sorry, I can't remember the exact instructions to turn this off (I only use Windows under VMware to test Samba:-).
Jeremy Allison, Samba Team.
Re:Does this ver. solve the WinXP security "featur
on
Samba 3.0.0 Released
·
· Score: 3, Informative
Not any more. We implemented sign&seal for Samba 3.0.
If it doesn't work when you remove this please log a bug at bugzilla.samba.org.
Slashdot Mirror
Andrew confused API's with protocols. Otherwise the article is correct.
Jeremy.
Well I'm a source, aren't I ? :-).
Seriously, I've never gone googling to track things down. I know what I know from writing code and working with/on Windows, nothing more. I haven't gone looking for "proof" of what I've learned from my own code and experiences - what would be the point for me ?
Jeremy.
Ok, contrast this :
:
:-) is to re-read these two and try and reconcile your argument. I may be arrogant and senile, but I'm *very* consistent :-).
:-).
"Of _course_ there is the concept of the local super user, there -has- to be on ANY OS. Whoopee!"
Your latest quote, with this
" Windows does not have root in the same sense Unix does."
Which was your initial statement I took great issue with.
Your assignment (should you choose to accept it
I don't think I can say the same about you
Jeremy.
"Well, if they really are *lying* and you can prove it, if I'm not mistaken there should be laws they can be prosecuted under."
Oh don't be ridiculous ! What, you think every single thing a manufacturer says about their product has to be true or they're prosecuted ? Wait a minute, you quoted textbooks from the University of Queensland. You're a student aren't you. That explains a lot about your simple view of the world and silly statements like that.
I stand by my "willfull ignorance" comment. You are willfully ignorant. There are no books that specificaly state "these facts Microsoft claims about their security model are lies". Why would anyone bother to publish such ? Just do some basic research to learn how things work. Don't just regurgitate OS textbooks at me. You're supposed to be at University to learn how to learn. This is a wonderful opportunity for you.
Jeremy.
No, not everything out there disagrees with what I say, only the text from Microsoft, and that written by authors who, like you, are just repeating what Microsoft tells then without actually writing code to *test* these claims.
They're lies. For example, the one that claims that even an Administrator cannot change ownership of a file from one user to another user without taking ownership first. Utter lies. Here's a hint, how do you think a restore from a backup can do this ?
You see, you don't code, you just read the propaganda and you're ignorant. You just believe what you're told. You don't have the skill to test it yourself, so you believe it when Microsoft tells you everything is fine, Windows is secure (if only people would apply those damn patches), and Linux has more security problems than Windows because Windows has a "secure design".
I suppose it's not your fault, but I hate willfull ignorance. If Windows were such a secure design, and there's no such thing as root why do you think there are so many viruses/worms that take over complete control of a machine ?
You remind me of the poor users who, in the early 90's, I ran into patiently waiting for "the Windows NT server to reboot". When I asked them why they weren't outraged by such poor service they replied "but that's what servers do !".
I have news for you, Microsoft *lies*. They lie to promote their own products, and they have convinced the gullable like you that mediocracy is acceptable in both design and implementation. Their security design is no different from UNIX. The reason you don't know that is because you're reading the wrong books.
I was amazed to see similar errors being made in O'Reillys recent book on secure code, in a discussion of the Windows security model. People don't bother to test, they just *assume*.
I don't assume. I have made my living writing code that *checks*. I can't assume what Microsoft says that Windows does is true, I have to interoperate on the wire. I actually have to write code that knows what Windows *does*. Go away and learn something.
Jeremy.
"You are making a very bold statement claiming every piece of literature describing Windows NT's architecture is lying."
Oh I see. Now your ignorance makes sense.
You're someone who doesn't program for Windows
or really understand its security model.
In other words, you just read the Microsoft
adverts and documentation, but you've never
written security code on Windows. Go away and
do so, learn something, then come back.
Jeremy.
"I'm sure when there's a CIFS bug you're quick to point out that this doesn't reflect badly on Windows"
When there's a CIFS implementation bug in Windows
(and remember we're the ones who have usually found it
and reported it to Microsoft) it reflects badly on the
CIFS server design in Windows (one multi-threaded mess,
embedded in the kernel that can bring down the system
if it crashes), not the CIFS protocol itself. This
is the Windows "low level architecture" you praise
so much. A CIFS server in the kernel... insanity !
The CIFS protocol has other problems, one of them
being it's too complicated to implement in a provably
secure mannor. Ask Microsoft why they don't serve
CIFS from ftp.microsoft.com any more. We were never
stupid enough to export CIFS from ftp.samba.org. We
don't consider CIFS an internet-safe protocol.
Jeremy.
"The Windows low level architecture is more powerful, you have more control over _everything_. "
This is untrue, that's what I'm trying to get you to understand.
In Windows, you have "root" and "not root", just like UNIX.
If you're root, the OS puts a lot of API barriers in your
way that you have to call through in order to add privillages
etc., but there's still nothing you can't do locally.
As for complaining about RPC holes, I don't think Windows
has much to be proud of here. DCE/RPC is overly complicated
for what it does. ONCE/RPC is a much simpler design, and
even it had some implementation security problems.
But even they are *nothing* compared to the pit of hell that
are the implementation security problems in Windows RPC. See
your local virus/worm vendor for details.
Jeremy.
Windows has root in *exactly* the same sense that UNIX does. :-). They *are* root. No, difference.
Do you think Administrator or LOCALSYSTEM on a box can't do
anything root can ? Change ownership of files to an arbitrary
SID (that's a lie in the Microsoft docs, claiming that can't
be done, I wrote a Win32 program to do just that about 11 years
ago
What you are complaining about is NFS, not UNIX.
Stop comparing *one* of the remote file system protocols in
the UNIX world with UNIX itself. And stop claiming that Windows
is architectured any differently. You're simply repeating
Microsoft propaganda, and people who know better will point
out you're lying. You're lying btw.
Jeremy.
If you think Windows doesn't have root, you're a fool. Worse,
an ignorant fool who propagates Microsoft propaganda as truth.
As for global access to network file systems, that's a NFS
flaw, not a UNIX one. Use a more secure remote file protocol,
like... gosh - how about *secure NFS* for one !
Jeremy.
He didn't write the code with that flaw in it, I did.
So did you get exploited by this flaw ? Did you lose data or
get compromised ? Do you have a legitimate complaint, or are
you carping anonymously about "communist collective's" because
you don't know how to code yourself, and you fear them ?
The psychology behind comments like this is interesting to me,
I always wonder if you're the same kind of people who "key"
expensive cars because you don't own one ? Did you ever write
software yourself ? Do you know how ?
Jeremy Allison,
Samba Team.
As I recall it breaks explorer, when deleting a :-).
:-).
tree of directories. I'd have to check the old
samba-bugs account to be sure. I didn't know
exporer was a 16 bit app
This is pretty obviously a benchmark special,
not run in production. I recognise things like
that, having done a few of them myself
Jeremy Allison,
Samba Team.
I don't deal with the design documents, I deal
in the protocol bits that the redirector actually
emits. And I had to fix this in Samba as not
mapping correctly back from 8.3 to long filenames
caused applications to break (I think it was the
W2K explorer shell, can't remember without going
back into the old samba-bugs mail). This is a
*required* feature.
I love this philosophy of "well the design docs
say it doesn't do that so obviously it doesn't".
The design docs say that ChangeNotify should work
with non NTSTATUS error code returns, but it
doesn't (and I've *seen* those design docs) !
The design docs don't mention that you can't
return ACLs on files unless you return unicode
paths for a qfileinfo request on ".", but that's
true also.
I suggest that you stop reading the design docs
and look at the code.
Jeremy Allison,
Samba Team.
"And the 8.3 fix isn't likely to break that many current apps. It certainly won't break any apps with a Win95 or greater logo, since the logo requirements for Win9x require that they support non 8.3 files."
Not true. You don't know anything about how the Windows redirector works, obviously. It's not just old W9x apps that use 8.3 filenames. The protocol demands that you can open a create a file with a long name, qfileinfo to get the short (8.3) name, then delete it with the 8.3 name.
The W2K redirector *DOES THIS*.
Don't make uninformed comments when you don't know the details.
Jeremy Allison,
Samba Team.
"A much better test would have been to let you in to tweak the
Samba/Linux server to the best of your abilities, and have the
Microsoft rep tweak the NT server to the best of their
abilities (allowing each of you to look over the others
shoulders to ensure neither side is cheating) and THEN run the
numbers."
No, I disagree, I think that would be a terrible test.
No one will run that way in production. The cheats and tweaks
you can do for netbench are *NOT* what you want in a production
system. And we would have to cheat to get good numbers, just in
case *they* were cheating to get good numbers (8.3 fix mentioned
above). This way lies madness, and no use to anyone.
The best kind of test is the one the vunet people did.
Just stick the damn thing on server hardware and run it
without any tuning on either side.
Jeremy Allison,
Samba Team.
> I haven't looked into Samba 3 yet, I have several Win2k
> domains, most of them in native mode. I'm interested to see
> how exactly a Samba 3 box would fit in a native mode domain.
It just works. That was one of the goals we had to
hit before release.
Jeremy Allison,
Samba Team.
> MS said that they improved file serving so it was "faster
> than the competition", which means it's as fast as Samba
No - it means they *said* it was as fast as Samba. Why do
you believe that remark and not the vunet one ?
They took some extreme liberties in that benchmark, see my
earlier comment for details.
I don't know which is faster, W2K3 or Samba. But I know
I'd trust a benchmark done by people who just put the software
onto a box and ran it more than a benchmark where I tweaked
Samba and the Linux box or one where Microsoft tweaked the
W2K3 box (which is the one you're referring to).
Real world use is what counts - how fast does it run in
*your* set up. Not how fast I or they can make it run in
some lab.
Jeremy Allison,
Samba Team.
They're a magazine, why would they have a bias towards Samba ? :-).
:
f t/ ms_netbench.pdf
:-), this would :-).
It isn't like we have a marketing budget and can pay them via advertising
Now a biased test is here
http://www.veritest.com/clients/reports/microso
The most damaging thing about the above link is that they
disabled 8.3 filename generation on the W2K3 server. In a
production environment this WILL BREAK APPLICATIONS !
I discussed this with tridge, and his humorous comment was
that if they were bending the rules this much we could just
set the server to discard the incoming data (as netbench
never actually reads back the data it writes
be about the same level of cheating
I didn't have anything to do with the vunet tests. But from
what the article says, they didn't do any tweaking on the
platforms. Which do you think is more valid in a real
environment - tuning to the amount given in the Microsoft
report, or just putting the software on the box and running
it, like the vunet report ?
I would hope that given access to such a netbench test and
being allowed to tune Samba and Linux to the extent that
Microsoft did I would be able to beat W2K3 in such a test
(opinion only, I haven't done such a test).
Jeremy Allison,
Samba Team.
Known bug - we intend to fix this for 3.0.1. We intend to
be able to export the Samba smbd keytab entry in the next
release (this is a request I've had inside HP as well).
Sorry for the problem you had.
Jeremy Allison,
Samba Team.
Yes it works.
Jeremy Allison,
Samba Team.
I wouldn't do it. And I write lots of the Samba code :-).
The protocol is just too complex to be sure any implementation
is safe.
Hopefully that should tell you something. It should also
tell you why we don't want it in the Linux kernel. Microsoft
put it in their kernel - I think that's a mistake.
Jeremy Allison,
Samba Team.
It means we do SMB signing by default now :-).
Jeremy Allison,
Samba Team.
No, they never did this. Oplocks are problematic in that
Windows boxes tend not to respond to oplock break requests
if there are *any* network problems. Most people have cheap
switches/hubs etc. For instance on my home network I can
only reliably ssh transfer a 100mb file over one of my
switches (the gigabit one), the 100Mbit switch will
consistantly corrupt the tcp stream causing ssh to abort.
oplocks need *reliable* networking hardware.
Jeremy Allison,
Samba Team.
It's probably the Web sharing service. Turn off the client :-).
side on the XP box. It tries to contact a port on the Samba
server that isn't open and times out. Sorry, I can't remember
the exact instructions to turn this off (I only use Windows
under VMware to test Samba
Jeremy Allison,
Samba Team.
Not any more. We implemented sign&seal for Samba 3.0.
If it doesn't work when you remove this please log
a bug at bugzilla.samba.org.
Thanks,
Jeremy Allison,
Samba Team.