Is noexec_user_stack supported in Solaris x86?
No. You can set it but it won’t do anything on Intel. On SPARC, it prevents execution of code that was placed on the stack. This is a popular technique used to gain unauthorized root access to systems, locally or remotely, by executing arbitrary code as root. This is possible with poorly-written programs that have missing overflow checks. To enable stack protection, add the following to /etc/system and reboot: set noexec_user_stack = 1 set noexec_user_stack_log = 1 Unfortuntely it’s ignored on the Intel Architecture, because it doesn’t have the concept of pages having execute permissions. (SPARC and AMD’s Opteron do, so it’s possible that a future release of Solaris x86 may support it when running on certain AMD CPU’s, but not on Intel ones.) This feature has been the default beginning with Solaris 9.
Yes, but only for AMD64 (Operon) on Solaris 10 or higher. For 32 bit x86, you can set it but it won’t do anything. On SPARC and AMD64, it prevents execution of code that was placed on the stack. This is a popular technique used to gain unauthorized root access to systems, locally or remotely, by executing arbitrary code as root. This is possible with poorly-written programs that have missing overflow checks. To enable stack protection, add the following to /etc/system set noexec_user_stack = 1 set noexec_user_stack_log = 1 and reboot with /usr/sbin/shutdown -i6 Unfortunately the flag is ignored on Intel 32-bit architecture, because it doesn’t have the concept of pages having execute permissions. (SPARC and AMD’s Opteron and Athlon support it though).
Yes, but only for AMD64 (Operon) on Solaris 10 or higher. For 32 bit x86, you can set it but it won’t do anything. On SPARC and AMD64, it prevents execution of code that was placed on the stack. This is a popular technique used to gain unauthorized root access to systems, locally or remotely, by executing arbitrary code as root. This is possible with poorly-written programs that have missing overflow checks. To enable stack protection, add the following to /etc/system set noexec_user_stack = 1 set noexec_user_stack_log = 1 and reboot with /usr/sbin/init 6 With Solaris 10 release it is clear that Solaris security is superior and architecturally is reached more advanced stage, especially in RBAC area and light-weight VM area (zones), than Linux security. I would say that Solaris 10 RBAC implementation and zones make it the first XXI century Unix. Red Hat implementation of SELinux in version 4 of Red Hat Enterprise makes it more competitive with Solaris then Suse, but still this is a less
No. You can set it but it won’t do anything on Intel. On SPARC, it prevents execution of code that was placed on the stack. This is a popular technique used to gain unauthorized root access to systems, locally or remotely, by executing arbitrary code as root. This is possible with poorly-written programs that have missing overflow checks. To enable stack protection, add the following to /etc/system and reboot: set noexec_user_stack = 1 set noexec_user_stack_log = 1 Unfortunately it’s ignored on the Intel Architecture, because it doesn’t have the concept of pages having execute permissions. (SPARC and AMD’s Opteron do, so it’s possible that a future release of Solaris x86 may support it when running on certain AMD CPU’s, but not on Intel ones.) This feature has been the default beginning with Solaris 9.
Yes, but only for AMD64 (Operon) on Solaris 10 or higher. For 32 bit x86, you can set it but it won’t do anything. On SPARC and AMD64, it prevents execution of code that was placed on the stack. This is a popular technique used to gain unauthorized root access to systems, locally or remotely, by executing arbitrary code as root. This is possible with poorly-written programs that have missing overflow checks. To enable stack protection, add the following to /etc/system set noexec_user_stack = 1 set noexec_user_stack_log = 1 and reboot with /usr/sbin/init 6 Unfortunately the flag is ignored on Intel 32-bit architecture, because it doesn’t have the concept of pages having execute permissions. (SPARC and AMD’s Opteron and Athlon support it though).
