FYI
-- Best regards, -- Boris.--Multipart_Tue_Dec_30_16:44:16_1997-1 Content-Type: message/rfc822
To: denis@jet.msk.su, asv@jet.msk.su, tobotras@jet.msk.su, dlg@jet.msk.su, galaxy@jet.msk.su Subject: Solaris 2.6 and stack executable permission Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Dec 1997 16:36:30 +0300 From: Denis Golubev <dlg@jet.msk.su> Message-Id: <E0xn1qQ-0006hV-00@h-10-166.service.jet.msk.su>
>From SunWorld Online 12/1997.
keywords - noexec_user_stack, noexec_user_stack_log
Executable stacks and security If you watch security bug reports, you'll notice that most of them involve overflowing the buffer on a process to escape from its limitations. For instance, setuid-programs try to provide specific functionality while not allowing a user full root access. If you escape from its programmed limits, you have full root access. These bugs are possible due to processes having execute access to their stacks. Unfortunately, the SPARC and Intel ABIs (application binary interfaces) require that stacks have those permissions. However, most programs function correctly even without stack execute permission.
A new system variable, noexec_user_stack, allows you to specify whether stacks are executable. It is set in /etc/system just like other system variables. At boot time, it is set to zero. Setting it to one results in non-executable stacks. An attempt to execute code on the stack will then cause a SIGSEGV signal and a warning message or a code dump, depending on whether the process traps that signal. The warning message is sent through syslog and by default ends up in /var/adm/messages.
Another system variable, noexec_user_stack_log can be set to zero to disable logging, but the signal may continue to cause the executing program to core dump.
There is also a system call, mprotect(2), that can be used within a program to explicitly mark its stack as executable.
Unfortunately, the stack protection is only available on modern Sun hardware, including the sun4m, sun4d and sun4u platforms. Note that the system needs to be rebooted after setting variables in /etc/system for the changes to take effect.
Of course, Solaris 2.6 has all of the security features of the previous Solaris releases. These include system security, network security, and authentication. /etc/default/login has important variables that control system-wide security, such as whether to allow root logins from non-console sources.
--Multipart_Tue_Dec_30_16:44:16_1997-1--