翻訳と辞書
Words near each other
・ Pawłówek, Ostrów Wielkopolski County
・ Pawłówek, Pułtusk County
・ Pawłówek, Sochaczew County
・ Pawłówek, Łódź Voivodeship
・ Pawłówka
・ Pawłówka, Lublin Voivodeship
・ Pawłówka, Masovian Voivodeship
・ Pawłówka, Podlaskie Voivodeship
・ Pawłówko
・ Pawłówko, Chojnice County
・ Pawłówko, Ciechanów County
・ Pawłówko, Człuchów County
・ Pawłówko, Gmina Buk
・ Pawłówko, Grodzisk Wielkopolski County
・ Pawłówko, Przasnysz County
PaX
・ Pax
・ Pax (album)
・ Pax (film)
・ Pax (goddess)
・ Pax (liturgical object)
・ Pax (liturgy)
・ Pax (Unix)
・ Pax aeterna
・ PAX AM
・ PAX AM Days
・ Pax Americana
・ Pax Americana and the Weaponization of Space
・ Pax Amicus Theatre
・ PAX Association


Dictionary Lists
翻訳と辞書 辞書検索 [ 開発暫定版 ]
スポンサード リンク

PaX : ウィキペディア英語版
PaX

PaX is a patch for the Linux kernel that implements least privilege protections for memory pages. The least-privilege approach allows computer programs to do only what they have to do in order to be able to execute properly, and nothing more. PaX was first released in 2000.
PaX flags data memory as non-executable, program memory as non-writable and randomly arranges the program memory. This effectively prevents many security exploits, such as some kinds of buffer overflows. The former prevents direct code execution absolutely, while the latter makes so-called return-to-libc (ret2libc) attacks difficult to exploit, relying on luck to succeed, but doesn't prevent overwriting variables and pointers.
PaX is maintained by The PaX Team, whose principal coder is anonymous.
==Significance==
Many, and perhaps even most, computer insecurities are due to errors in programs that make it possible to alter their function, effectively allowing them to be "rewritten" while running. The first 44 Ubuntu Security Notices can be categorized 〔(Analysis of the Ubuntu Linux Security Notices )〕 to show that 41% of vulnerabilities stem from buffer overflows, 11% from integer overflows, and 16% from other bad handling of malformed data. These types of bugs often open the possibility to inject and execute foreign code, or execute existing code out of order, and make up 61% of the sample group, discarding overlap. (This is a crude analysis; a more comprehensive analysis of individual vulnerabilities would be likely to give very different numbers.)
Many worms, viruses, and attempts to take over a machine rely on changing the contents of memory so that the malware code is executed; or on executing "data" contents by misdirection. If execution of such malware could be blocked, it could do little or even no damage even after being installed on a computer; many, such as the Sasser worm, could be prevented from being installed at all.
PaX was designed to do just that for a large number of possible attacks, and to do so in a very generally applicable way. It prevents execution of improper code by controlling access to memory (read, write, or execute access; or combinations thereof) and is designed to do so without interfering with execution of proper code. At the cost of a small amount of overhead, PaX reduces many security exploits to a denial of service (DoS) or a remote code-flow control; exploits which would normally give attackers root access, allow access to important information on a hard drive, or cause other damage that will instead cause the affected program or process to crash with little effect on the rest of the system.
A DoS attack (or its equivalent) is generally an annoyance, and may in some situations cause loss of time or resources (e.g. lost sales for a business whose website is affected); however, no data should be compromised when PaX intervenes, as no information will be improperly copied elsewhere. Nevertheless, the equivalent of a DoS attack is in some environments unacceptable; some businesses have level of service contracts or other conditions which make successful intruder entry a less costly problem than loss of or reduction in service. The PaX approach is thus not well suited to all circumstances; however, in many cases, it is an acceptable method of protecting confidential information by preventing successful security breaches.
Many, but not all, programming bugs cause memory corruption. Of those that do, and are triggerable by intent, some will make it possible to induce the program to do various things it was not meant to, such as producing a high-privilege shell. The focus of PaX is not on the finding and fixing of such bugs, but rather on prevention and containment of exploit techniques which may stem from such programmer error. A subset of these bugs will be reduced in severity; programs terminate, rather than improperly provide service.
PaX does not directly prevent buffer overflows; instead, it effectively prevents many of these and related programming bugs from being used to gain unauthorized entry into a computer system. Other systems such as Stack-Smashing Protector and StackGuard do attempt to directly detect buffer overflows, and kill the offending program when identified; this approach is called stack-smashing protection, and attempts to block such attacks before they can be made. PaX's more general approach, on the other hand, prevents damage after the attempt begins. Although both approaches can achieve some of the same goals, they are not entirely redundant. Therefore, employing both will, in principle, make an operating system more secure. Some Linux distributions already use the PaX with Stack Smash Protection combination.
As of mid-2004, PaX has not been submitted to the mainline kernel tree because The PaX Team does not find it appropriate yet; although PaX is fully functional on many CPU architectures, including the widely used x86 architecture, it still remains partially or fully unimplemented on some architectures. Those that PaX is effective on include IA-32 (x86), AMD64, IA-64, Alpha, PA-RISC, and 32 and 64 bit MIPS, PowerPC, and SPARC architectures.

抄文引用元・出典: フリー百科事典『 ウィキペディア(Wikipedia)
ウィキペディアで「PaX」の詳細全文を読む



スポンサード リンク
翻訳と辞書 : 翻訳のためのインターネットリソース

Copyright(C) kotoba.ne.jp 1997-2016. All Rights Reserved.