Microsoft Windows, a lower Total Cost of Ownership

[Hal2001]

La Immunity, Inc., nella persona del suo CEO, Dave Aitel, ha pubblicato un documento dove analizza i costi nell'implementare Fedora Core 2 contro il monopolista Microsoft Windows, fa anche dei riferimenti a quello che definisce il giocattolo di Apple, MacOSX.

Qui la pagina con i documenti: http://www.immunitysec.com/resources-papers.shtml
proposto in formato OpenOffice:
- http://www.immunitysec.com/downloads/tc0.sxw
e in Acrobat:
- http://www.immunitysec.com/downloads/tc0.pdf

Based on our analysis, Microsoft Windows has one half the Total Cost
of 0wnership (TC0) of modern Fedora Core Linux based technologies.

E' in inglese. A voi i commenti

[elypepe]

la Mikrozoz continua a mentire e infangare Gnu-Linux/Open Source.
sicuramente le marmotte hanno cominciato a fare la cioccolatta a Seattle

[Ikitt_Claw]

Originariamente inviato da Hal2001
Qui la pagina con i documenti: http://www.immunitysec.com/resources-papers.shtml
proposto in formato OpenOffice:
- http://www.immunitysec.com/downloads/tc0.sxw
e in Acrobat:
- http://www.immunitysec.com/downloads/tc0.pdf
E' in inglese. A voi i commenti

Il mio commento e`: sono d'accordo in larga parte con questo studio
Che si riferisce allo sforzo necessario per prendere possesso, nel senso di hackerare (to 0wn, "Fluffy Bunny 0wnz Y0u"), non di mantenere!

[NA01]

ne esce uno alla settimana....
però li leggo sempre tutti, mi divertono un sacco
bello il grafico all'inizio, dà l'idea della serierà dell'analisi.
sono invece daccordo con il concetto del lago e dei pescatori, peccato che non so quanti buchi abbia scoperto mia madre o mia sorella (assidue utilizzatrici di win)... credo di vincere io (che mi mantengo a quota 1 ).
il capitolo Time to 0day è da denuncia.... non credo sia mai successa una cosa del genere, almeno non mentre io usavo win
quanto ai dati su fc non so.... non la ho mai usata a lungo

arriviamo poi alla leggenda fatta capitolo.....
Kernel-level defenses
veramente un bel capitolo... parla di pax e di un sacco di altre cose, ammette candidamente che win non ha nulla del genere e che forse in un lontano futuro si farà qualcosa ( )... poi il capitolo si conclude con un colpo di scena degno del miglior giallista in circolazione....

The TC0 advantage is clearly for the Windows Platform.

arriviamo a momenti di onestà disorientante, compensati da abbondante spiegazione:

Library Defenses
Modern Windows (as of XP SP2) contains heap overflow protection. This raises its TC0 dramatically, but is not yet in production and has not been considered for this survey.

sulla prime parole mi sembrava quasi sfavorevole a win, meno male che ci abbiano ripensato....

PS: qualcuno ha una spiegazione razionale su keren defenses???
spero di avel capito male io li'inglese

cia

[gohan]

probabilmente mia sorella di 7 anni avrebbe scritto meglio quel capitolo, però posso fare presente che il nuovo SP2 ha tutti i componenti di windows ricompilati in modo che non siano più possibili buffer overflow di fatto rendendo inutili programmi tipo PaX (se ho capito bene a cosa serve pax)

[NA01]

si, grsecurity (che continene anche pax) serve in gran parte anche a questo.
poi fa un sacco di belle cosine:

grsecurity 2.0 RBAC features

* Role-Based Access Control
* User, group, and special roles
* Domain support for users and groups
* Role transition tables
* IP-based roles
* Non-root access to special roles
* Special roles that require no authentication
* Nested subjects
* Variable support in configuration
* And, or, and difference set operations on variables in configuration
* Object mode that controls the creation of setuid and setgid files
* Create and delete object modes
* Kernel interpretation of inheritance
* Real-time regular-expression resolution
* Ability to deny ptraces to specific processes
* User and group transition checking and enforcement on an inclusive or exclusive basis
* /dev/grsec entry for kernel authentication and learning logs
* Next-generation code that produces least-privilege policies for the entire system with no configuration
* Full pathnames for offending process and parent process
* RBAC status function for gradm
* /proc/<pid>/ipaddr gives the remote address of the person who started a given process
* Secure policy enforcement
* Supports read, write, append, execute, view, and read-only ptrace object permissions
* Supports hide, protect, and override subject flags
* Supports the PaX flags
* Shared memory protection feature
* Integrated local attack response on all alerts
* Subject flag that ensures a process can never execute trojaned code
* Full-featured fine-grained auditing
* Resource, socket, and capability support
* Protection against exploit bruteforcing
* /proc/pid filedescriptor/memory protection
* Rules can be placed on non-existent files/processes
* Policy regeneration on subjects and objects
* Configurable log suppression
* Configurable process accounting
* Human-readable configuration
* Not filesystem or architecture dependent
* Scales well: supports as many policies as memory can handle with the same performance hit
* No runtime memory allocation
* SMP safe
* O(1) time efficiency for most operations
* Include directive for specifying additional policies
* Enable, disable, reload capabilities
* Option to hide kernel processes

Chroot restrictions

* No attaching shared memory outside of chroot
* No kill outside of chroot
* No ptrace outside of chroot (architecture independent)
* No capget outside of chroot
* No setpgid outside of chroot
* No getpgid outside of chroot
* No getsid outside of chroot
* No sending of signals by fcntl outside of chroot
* No viewing of any process outside of chroot, even if /proc is mounted
* No mounting or remounting
* No pivot_root
* No double chroot
* No fchdir out of chroot
* Enforced chdir("/") upon chroot
* No (f)chmod +s
* No mknod
* No sysctl writes
* No raising of scheduler priority
* No connecting to abstract unix domain sockets outside of chroot
* Removal of harmful privileges via capabilities
* Exec logging within chroot

Address space modification protection

* PaX: Page-based implementation of non-executable user pages for i386, sparc, sparc64, alpha, parisc, amd64, ia64, and ppc; negligible performance hit on all i386 CPUs but Pentium 4
* PaX: Segmentation-based implementation of non-executable user pages for i386 with no performance hit
* PaX: Segmentation-based implementation of non-executable KERNEL pages for i386
* PaX: Mprotect restrictions prevent new code from entering a task
* PaX: Randomization of stack and mmap base for i386, sparc, sparc64, alpha, parisc, amd64, ia64, ppc, and mips
* PaX: Randomization of heap base for i386, sparc, sparc64, alpha, parisc, amd64, ia64, ppc, and mips
* PaX: Randomization of executable base for i386, sparc, sparc64, alpha, parisc, amd64, ia64, and ppc
* PaX: Randomization of kernel stack
* PaX: Automatically emulate sigreturn trampolines (for libc5, glibc 2.0, uClibc, Modula-3 compatibility)
* PaX: No ELF .text relocations
* PaX: Trampoline emulation (GCC and linux sigreturn)
* PaX: PLT emulation for non-i386 archs
* No kernel modification via /dev/mem, /dev/kmem, or /dev/port
* Option to disable use of raw I/O
* Removal of addresses from /proc/<pid>/[maps|stat]

Auditing features

* Option to specify single group to audit
* Exec logging with arguments
* Denied resource logging
* Chdir logging
* Mount and unmount logging
* IPC creation/removal logging
* Signal logging
* Failed fork logging
* Time change logging

Randomization features

* Larger entropy pools
* Randomized TCP Initial Sequence Numbers
* Randomized PIDs
* Randomized IP IDs
* Randomized TCP source ports
* Randomized RPC XIDs

Other features

* /proc restrictions that don't leak information about process owners
* Symlink/hardlink restrictions to prevent /tmp races
* FIFO restrictions
* Dmesg(8) restriction
* Enhanced implementation of Trusted Path Execution
* GID-based socket restrictions
* Nearly all options are sysctl-tunable, with a locking mechanism
* All alerts and audits support a feature that logs the IP address of the attacker with the log
* Stream connections across unix domain sockets carry the attacker's IP address with them (on 2.4 only)
* Detection of local connections: copies attacker's IP address to the other task
* Automatic deterrence of exploit bruteforcing
* Low, Medium, High, and Custom security levels
* Tunable flood-time and burst for logging

mi sa che mi devo cercare una ragazza, ho un pò troppo tempo da perdere

[crashd]

microzozz mi fa sempre più pena
aspetta che qualche boccalone creda alle sue idiozie
:eheh: io ci rido su :eheh: :eheh:

[crashd]

Originariamente inviato da NA01
mi sa che mi devo cercare una ragazza, ho un pò troppo tempo da perdere

:eheh:
anch'io

[gohan]

però mi sembra un po' ingiusto scrivere accuse a MS solo perchè avete il sospetto che il tutto sia organizzato....
Se anche RedHat facesse una cosa simile, probabilmente direbbe che è linux a costare meno......

[Ikitt_Claw]

Originariamente inviato da gohan
Se anche RedHat facesse una cosa simile, probabilmente direbbe che è linux a costare meno......

In questo caso, direbbe che e` linux a costare di piu`...

[gohan]

e per quale motivo dovrebbe dire ciò?

[Ikitt_Claw]

Originariamente inviato da gohan
e per quale motivo dovrebbe dire ciò?

Perche` nel contesto dello studio di cui si dibatte in questo thread, un maggior costo di possesso e` desiderabile:

[...]In each those, the cost to penetrate (0wn) systems based on a Microsoft Windows Technologies was compared to the costs against a modern Linux system.

Maggior costo di possesso == maggiore resistenza alle aggressioni

Tratto da pagina 4, "Immunity's Methodology".

[EDIT] corretto mio GRAVE errore nell'esposizione [/EDIT]

[gohan]

Originariamente inviato da Ikitt_Claw
Perche` in base allo studio di cui si dibatte in questo thread, un maggior costo di possesso e` desiderabile:

Maggior costo di possesso == maggiore resistenza alle aggressioni

Tratto da pagina 4, "Immunity's Methodology".

non sono poi così d'accordo con questa affermazione....
cmq le aziende di solito scelgono i sistemi col minor TCO.

[Ikitt_Claw]

Originariamente inviato da gohan
non sono poi così d'accordo con questa affermazione....
cmq le aziende di solito scelgono i sistemi col minor TCO.

Ovviamente.

In questo contesto "Ownership" e` usata pero` con significato diverso (opposto, quasi) rispetto al solito. Tant'e` che e` anche scritto in modo diverso. Un gioco di parole, insomma.
Quel pezzo quotato in inglese lascia pochi dubbi, IMHO.