Just to mention it again http://www.google.com/#q=inurl:wth_the_proc_pid_mem_problem

It’s at least EIGHTS security ONLY problem in the relatively small area which is /proc/pid/mem.
Have anyone ever heard about SINGLE vulnerability in a WriteProcessMemory? Oh, but those guys don’t have million vigilant eyes and superior development process.

For the sake of consistency here, I should mention that I regard WriteProcessMemory() as an equivalently stupid idea.

But “WriteProcessMemory” doesn’t make everything a “file”(TM).

Or, by ESR’s logic, this means a lack of proper “metaphors”, meaning that your OS will simply break your stuff in one way or another in every release.

It all makes sense.

> I regard WriteProcessMemory() as an equivalently stupid idea.

Why so? It’s covered by the same security mechanisms as everything else. You should either have an explicit ACE allowing you to write to that process or have SeDebugPrivilege (basically belong to Administrators group and even they could have this privilege stripped).

That’s because there is a basic rule: before using any resource (process memory included), you should pass permission checks first. Combined with the simplicity of ACCESS_TOKEN/SECURITY_DESCRIPTOR model it gives us security reference monitor – concept from 70-th.

Who the fsck is this idiot (from your pog-blog link):

“And by the way, if you knew about kernels, you know that Windows kernels are very vulnerable as it is a simple DLL file which is located within the OS, which makes it easy for simple attacks on a system. If someone hacks into the Windows folder, you are buggered as you do not need permissions. With a *nix kernel, you would know it is underlying software, which the OS works on top of, it is not a library; unless you had the superuser’s credentials you cannot compromise anything, and even if you did with your own hands there are other kernel versions you can fallback with a previous version; or compile a newer version from source.”

What kind of mashed potatoes + guacamole + a bit of bullsh1t mix does he have instead of brains?

“What kind of mashed potatoes + guacamole + a bit of bullsh1t mix does he have instead of brains?”

That’s an interesting question – one that must also ask upon seeing /proc/(pid)/mem.

Back on the subject – does the guy know how a DLL works, or even simply what a “DLL” is? The mind boggles.

It’s not even about dll (kernel.dll doesn’t even exist and kernel32.dll/kernelbase.dll is not even, you know, a kernel), but the part I liked the most is that “once you’ve hacked into Windows dir – you don’t need permissions” vs “that superior superuser stupidity”.

Yeah, that’s right – once you’ve elevated yourself to TrustedInstaller (not even SYSTEM has write access to Windows’s system files) you don’t have to care about permissions anymore. That elevation should be a trivial thing, right? Though, I have that strange feeling that logic is warped somewhere. LinuxSecurityExperts™ FTW

Ah, and if you start with “if you knew about kernels” it instantly gives you +150 Credibility and you can continue with any bullcrap you want – everyone will believe you without any questions.

“Yeah, that’s right – once you’ve elevated yourself to TrustedInstaller (not even SYSTEM has write access to Windows’s system files) you don’t have to care about permissions anymore.”

The same could be said about vmlinux – just don’t tell “Mr. Hill” about that.

I find the DLL part fascinating because it seems that it is one of the most frequently tossed-around things about Windows that LinuxSecurityExperts™ simply lack understanding of. This is, of course, not to mention the inadvertent association of the NT kernel to Windows 98, the utter ignorance of ACEs and how they work, and so forth.

one of the flaws that Windows has it that it doesn’t have on the fly driver injection. you have to manually write a custom .reg file. so if I change my raid card the official way that MS tells you is that i’ll have to do a repair install and add the raid driver then. I came across that issue a few times before. obviously it is less headache to figure out to inject the darn thing manually then face other breakages from the repair install.

@garegin
Windows doesn’t have (never had) this “flaw” (try “sc create” and look at the “type” argument carefully) or closer to how things actually work: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682450 with dwServiceType == SERVICE_KERNEL_DRIVER

This is mostly used for legacy (NT3.5 style) drivers. Newer drivers should have inf file and should be installed through SetupAPI. devcon.exe is distributed as part of WDK if you prefer to mess around with CLI.

This way, drivers are loaded and actual DEVICE_OBJECTs are created on demand – when system needs them (and decision about what driver to load is made based on that inf file, I’ve mentioned before).

Whatever way you choose, you can add, start and stop drivers on the fly (well, with WDM type you can’t really control that – but system itself can).

Just to chime in, a bazaar model can, and often does, employ QA, testing, etc. if it’s done in an agile manner. But many of the bazaar proponents think “agile development” means “developing really fast”.

In actuality, agile means being able to quickly change course, not release a semi-functional build every day. It ensures that your product is always in a working state and doesn’t remain in a developmental black box for ages. It means each feature goes through the process of specing, development, testing, regression, QA, etc. rather than the entire project all at once.

I can tell you that most package development that think they’re agile, are not.

“But many of the bazaar proponents think 'agile development’ means 'developing really fast’.”

That depends on how long you have been drinking the Kool-Aid:

http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html

That said, I do believe this “bazaar vs. cathedral” thing is a form of Kool-Aid by it own rights.

it -> its

It looks like FOSS has even bigger problem, than constant issues with funding or ignoring QA altogether. At least there are SOME working business models and there is nothing that prevents them from creating tests/QA.

The worst thing is that Bazaar is COMPLETELY unable to design. Look, there is that famous thing called http://en.wikipedia.org/wiki/Design_by_committee meaning worst design that one could imagine. Now, remember that in committee members meet each other, have strict processes (and some leadership – even if it’s poor) in place, they document everything, there is a quite high barrier (education/skills/experience) to entry etc. – everything Bazaar lacks.

The ONLY way Bazaar could produce something is through brainless patching over patches over patches over patches (DuctTapeDevelopment™). That’s why FOSS is often so disgustingly stupid

“Ah, and if you start with “if you knew about kernels” it instantly gives you +150 Credibility… “

Ah, but I know about kernels – I’ve read Tannenbaum’s book (On a serious note, I’ve done other things too, so I have some basic knowledge). Should I go debunk him? What happens we both 'know about kernels’? What happens when an unstoppable force meets an immovable object?

In answer to the question “Who the fsck is this idiot?” — I presume Mr Hill; I don’t read Pog at work — he’s a recent addition to the menagerie. He does WallOfGibberish™ just as well as oiaohm, but sadly is considerably less well informed. In fact, the’s breathtakingly ignorant.

I believe he was scraped off the floor at Tech Rights, but I haven’t been inclined to check that, either.

What is it with Loons and DLLs? Are COFF files supposed to be magically less secure than ELF files, for some reason? Do these people have an ounce of sense?

Probably not. I’ve just found the following in Wikipedia under ELF:

“Unlike many proprietary executable file formats, ELF is flexible and extensible, and it is not bound to any particular processor or architecture.”

But, on the other hand, exactly like the proprietary executable file format COFF (which was originally prefixed with “portable executable”). FUD going strong here, then.

Is the Pog Blog down?

Yep, it’s down.

The scalability and performance of Linux in action!

Yes, maybe you and Dr Loser tried to connect at the same time. :)