JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris 11.1 Administration: Security Services     Oracle Solaris 11.1 Information Library
search filter icon
search icon

Document Information


Part I Security Overview

1.  Security Services (Overview)

Part II System, File, and Device Security

2.  Managing Machine Security (Overview)

3.  Controlling Access to Systems (Tasks)

4.  Virus Scanning Service (Tasks)

5.  Controlling Access to Devices (Tasks)

6.  Verifying File Integrity by Using BART (Tasks)

7.  Controlling Access to Files (Tasks)

Using UNIX Permissions to Protect Files

Commands for Viewing and Securing Files

File and Directory Ownership

UNIX File Permissions

Special File Permissions (setuid, setgid and Sticky Bit)

setuid Permission

setgid Permission

Sticky Bit

Default umask Value

File Permission Modes

Using Access Control Lists to Protect UFS Files

Protecting Executable Files From Compromising Security

Protecting Files (Tasks)

Protecting Files With UNIX Permissions (Task Map)

How to Display File Information

How to Change the Owner of a File

How to Change Group Ownership of a File

How to Change File Permissions in Symbolic Mode

How to Change File Permissions in Absolute Mode

How to Change Special File Permissions in Absolute Mode

Protecting Against Programs With Security Risk (Task Map)

How to Find Files With Special File Permissions

How to Disable Programs From Using Executable Stacks

Part III Roles, Rights Profiles, and Privileges

8.  Using Roles and Privileges (Overview)

9.  Using Role-Based Access Control (Tasks)

10.  Security Attributes in Oracle Solaris (Reference)

Part IV Cryptographic Services

11.  Cryptographic Framework (Overview)

12.  Cryptographic Framework (Tasks)

13.  Key Management Framework

Part V Authentication Services and Secure Communication

14.  Using Pluggable Authentication Modules

15.  Using Secure Shell

16.  Secure Shell (Reference)

17.  Using Simple Authentication and Security Layer

18.  Network Services Authentication (Tasks)

Part VI Kerberos Service

19.  Introduction to the Kerberos Service

20.  Planning for the Kerberos Service

21.  Configuring the Kerberos Service (Tasks)

22.  Kerberos Error Messages and Troubleshooting

23.  Administering Kerberos Principals and Policies (Tasks)

24.  Using Kerberos Applications (Tasks)

25.  The Kerberos Service (Reference)

Part VII Auditing in Oracle Solaris

26.  Auditing (Overview)

27.  Planning for Auditing

28.  Managing Auditing (Tasks)

29.  Auditing (Reference)



Protecting Executable Files From Compromising Security

Programs read and write data on the stack. Typically, they execute from read-only portions of memory that are specifically designated for code. Some attacks that cause buffers on the stack to overflow try to insert new code on the stack and cause the program to execute it. Removing execute permission from the stack memory prevents these attacks from succeeding. That is, most programs can function correctly without using executable stacks.

64-bit processes always have non-executable stacks. By default, 32-bit SPARC processes have executable stacks. The noexec_user_stack variable enables you to specify whether the stacks of 32-bit processes are executable.

Once this variable is set, programs that attempt to execute code on their stack are sent a SIGSEGV signal. This signal usually results in the program terminating with a core dump. Such programs also generate a warning message that includes the name of the offending program, the process ID, and the real UID of the user who ran the program. For example:

a.out[347] attempt to execute code on stack by uid 555 

The message is logged by the syslog daemon when the syslog kern facility is set to notice level. This logging is set by default in the syslog.conf file, which means that the message is sent to both the console and the /var/adm/messages file. For more information, see the syslogd(1M) and syslog.conf(4) man pages.

The syslog message is useful for observing potential security problems. The message also identifies valid programs that depend upon executable stacks that have been prevented from correct operation by setting the noexec_user_stack variable. If you do not want any messages logged, then set the log variable, noexec_user_stack_log, to zero in the /etc/system file. Even though messages are not being logged, the SIGSEGV signal can continue to cause the executing program to terminate with a core dump.

Programs can explicitly mark or prevent stack execution. The mprotect() function in programs explicitly marks the stack as executable. For more information, see the mprotect(2) man page. A program compiled with -M /usr/lib/ld/map.noexstk makes the stack non-executable regardless of the system-wide setting.