Intel® IoT Gateway - Security Profiles
Whitepaper
December 2014
Revision: 1.0
Legal Disclaimers
Legal Disclaimers
By using this document, in addition to any agreements you have with Intel, you accept the terms set forth below.
You may not use or facilitate the use of this document in connection with any infringement or other legal analysis concerning
Intel products described herein. You agree to grant Intel a non-exclusive, royalty-free license to any patent claim thereafter
drafted which includes subject matter disclosed herein.
INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED,
BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT.
Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the
absence or characteristics of any features or instructions marked "reserved" or "undefined". Do not finalize a design with this
information.
The products described in this document may contain design defects or errors known as errata which may cause the product to
deviate from published specifications. Current characterized errata are available on request.
Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your product order.
Code Names are only for use by Intel to identify products, platforms, programs, services, etc. (“products”) in development by
Intel that have not been made commercially available to the public, i.e., announced, launched or shipped. They are never to be
used as “commercial” names for products. Also, they are not intended to function as trademarks.
Copies of documents which have an order number and are referenced in this document, or other Intel literature, may be obtained
by calling 1-800-548-4725, or go to: http://www.intel.com/design/literature.htm
Intel, Intel Atom, Intel Core, Intel® Hyper-Threading Technology, Intel logo are trademarks or registered trademarks of Intel
Corporation or its subsidiaries in the United States and other countries.
Wind River is a trademark of Wind River Systems, Inc.
*Other names and brands may be claimed as the property of others.
Copyright © 2014, Intel Corporation. All rights reserved.
Intel® IoT Gateway - Security Profiles
Whitepaper
2
December 2014
Document # 331648-001
Contents
Contents
1
Introduction ........................................................................................ 5
1.1
1.2
2
Security Features of Intel® IoT Gateway .................................................. 8
2.1
2.2
2.3
2.4
3
Secure Boot ............................................................................... 8
GRSecurity ................................................................................ 9
2.2.1
GRSecurity Administration Utility (gradm) ......................... 10
2.2.2
GRSecurity Full Learning Mode......................................... 10
2.2.3
RBAC Policies Using Full System Learning Mode.................. 10
McAfee* Embedded Control......................................................... 11
Integrity Measurement Architecture (IMA)..................................... 13
Security Profiles for Intel® IoT Gateway.................................................. 14
3.1
3.2
3.3
4
About this Document .................................................................. 6
Related Documents ..................................................................... 6
Secure
Secure
3.2.1
Secure
3.3.1
3.3.2
Boot .............................................................................. 15
Boot with GRSecurity and McAfee Embedded Control ............ 15
Workflow to Enable GRSecurity and McAfee Embedded Control15
Boot with GRSecurity and IMA .......................................... 19
Workflow to Enable GRSecurity and IMA............................ 19
PaX.............................................................................. 22
Summary ........................................................................................... 29
Appendix A Sample PaX Usage .............................................................................. 30
A.1
A.2
Sample a.c File ......................................................................... 30
Sample attack.c File ................................................................... 31
Appendix B Questions and Answers ........................................................................ 32
B.1
B.2
Both IMA and McAfee Embedded Control are configured and enabled,
but IMA is blocking my file or process .......................................... 32
Why are symbolic links removable in McAfee Embedded Control even
though whitelisted? ................................................................... 32
Figures
Figure 1.
Intel Secure Boot High Level Flow Diagram........................................................................................... 9
Tables
Table 1.
Table 2.
Related Documents .......................................................................................................................................... 6
Pre-OS and Post-OS protections .............................................................................................................14
December 2014
Document # 331648-001
Intel® IoT Gateway - Security Profiles
Whitepaper
3
Revision History
Revision History
Date
Revision
December 2014
1.0
Intel® IoT Gateway - Security Profiles
Whitepaper
4
Description
Initial public release
December 2014
Document # 331648-001
Introduction
1
Introduction
This whitepaper provides technical descriptions of security profiles that can be
found on the Intel® IoT Gateway, and provides technical guidance on the
setup of these security profiles. This whitepaper pays particular attention to
the configuration of GRSecurity with McAfee* Embedded Control and Integrity
Measurement Architecture (IMA).
In this document:
NOTE:
•
Security Profile is one or more security features that meet an
objective for security protection.
•
Secure Boot refers to hardware based protection features and device
initialization flows at system startup that ensure only authenticated
and trusted software is allowed to execute.
•
GRSecurity is a configurable policy that allows collections of
programs or process to be executed as least-privilege. It contains a
Role Base Access Control (RBAC) mechanism that restricts system
access via creating a least-privilege system. GRSecurity contains a
PaX structure that prevents executable memory pages from being
overwritten with injected machine code. This prevents exploitation of
many types of security vulnerabilities, such as buffer overflows.
•
McAfee Embedded Control is a security feature that provides
protection of system integrity by controlling what is being run on the
embedded device and a way to monitor file system changes. McAfee
Embedded Control allows only authorized software to run, permits
validated changes, tracks file system changes and provides capability
to protect critical data files from being tampered.
•
IMA is Integrity Measurement Architecture, a security feature that has
the ability to detect if files have been accidentally or maliciously
altered, both remotely and locally. IMA offers appraisal and signing
onto a file's measurement against a "good" value stored as an
extended attribute, and enforce local file integrity including appraisal
hash protection.
Details about the Intelligent Device Platform software are in the Wind River
Intelligent Device Platform Programmer’s Guide, listed in Table 1.
December 2014
Document # 331648-001
Intel® IoT Gateway - Security Profiles
Whitepaper
5
Introduction
1.1
About this Document
Section 2 provides a brief explanation of the security features. This document
does not explain each security features in detail. Detailed information is
available in the Wind River Intelligent Device Platform Security Guide.
Section 3 provides a review of the Security Profiles, including the
configurations and instructions to utilize various profiles to achieve your
security objectives.
This font used within a paragraph indicates command line entries,
parameters, filenames, directory paths, etc.
This font in a gray box indicates commands or scripts that you
need to type, or other code examples that might be a useful
reference.
This font in a green box indicates a command response or another
type of screen display.
1.2
Related Documents
Table 1.
Related Documents
Document Title
Document Location
Wind River Intelligent Device Platform XT Programmer’s Guide
https://wwwssl.intel.com/content/www/
us/en/embedded/designtools/evaluationplatforms/gatewaysolutions/wind-river-idpxt2-programmersguide.html?wapkw=wind+ri
ver
Wind River Intelligent Device Platform XT Security Guide
http://www.intel.com/conte
nt/www/us/en/embedded/d
esign-tools/evaluationplatforms/gatewaysolutions/wind-river-idpsecurityguide.html?wapkw=security
+guide
Intel® IoT Gateway - Security Profiles
Whitepaper
6
December 2014
Document # 331648-001
Introduction
Document Title
Document Location
Intel® Quark™ SoC X1000: Platform Design Guide
http://www.intel.com/conte
nt/www/us/en/embedded/pr
oducts/quark/quark-x1000platform-design-guide.html
Intel® Quark™ SoC X1000 UEFI Firmware Writer’s Guide
http://www.intel.com/conte
nt/www/us/en/intelligentsystems/quark/quarkx1000-uefi-firmwarewriters-guide.html
User Guide: McAfee Embedded Control 6.1.0
http://www.intel.com/conte
nt/www/us/en/embedded/d
esign-tools/evaluationplatforms/gatewaysolutions/mcafeeembedded-control-userguide.html?wapkw=embedd
ed+control
For use with Wind River Linux 5.0.1
Command Line Interface Guide: McAfee Application Control
6.1.0
For use in standalone mode
December 2014
Document # 331648-001
http://www.intel.com/conte
nt/www/us/en/embedded/d
esign-tools/evaluationplatforms/gatewaysolutions/mcafeeapplication-control-cliguide.html?wapkw=comma
nd+line+interface+guide
Intel® IoT Gateway - Security Profiles
Whitepaper
7
Security Features of Intel® IoT Gateway
2
Security Features of Intel® IoT Gateway
2.1
Secure Boot
Secure Boot uses a security table and keys plus a signed kernel image and
rootfs image to verify that the kernel image and file system have not been
tampered with before allowing the boot to proceed.
The Secure Boot feature offers a pre-OS or pre-kernel security protection
mechanism to meet your security objective of a root of trust. In a high level
logical approach, the UEFI Secure Boot implementation involves:
1. BIOS to verify all modules before launch
2. BIOS to verify OS boot loader before launch
3. The platform fails to boot if verification fails
The UEFI 2.2 specification added the Secure Boot protocol with a goal of
securing the boot process by preventing loading UEFI drivers or OS loaders
that are not signed with an acceptable digital signature. Secure Boot aids in
preventing attacks on pre-OS level types of vulnerabilities. It is managed by a
read-only UEFI global variable (ON/OFF).
The Intel hardened UEFI Secure Boot with Platform “Root of Trust”:
•
Anchor establishes initial trust and extends through the remainder of
the boot flow.
•
Is grounded in Intel processors, such as Intel® Quark™ and Atom™
processors.
•
SHA256 Hash is used in RSA Encrypt to generate a Secure Boot
signature.
•
Uses public-key cryptography, also known as asymmetric
cryptography.
Intel® IoT Gateway - Security Profiles
Whitepaper
8
December 2014
Document # 331648-001
Security Features of Intel® IoT Gateway
Figure 1.
Intel Secure Boot High Level Flow Diagram
For a complete description, and installation and setup steps, see the Wind
River Intelligent Device Platform Programmer’s Guide. See Table 1 for other
documents that contain detailed information about Secure Boot.
2.2
GRSecurity
GRSecurity is a set of free software patches released under the GNU GPL for
the Linux kernel to enhance the system security. It allows you to define a
minimum privilege policy for the system in which every process and user has
only the lowest privileges necessary to function. GRSecurity has two primary
features:
•
Role-based access control (RBAC) provides full learning mode for
generating security policy rules. The default policy is located in the
/etc/grsec/policy file.
•
PaX flags data memory on the stack as non-executable and program
memory as non-writable. It is a set of patches applied to the Linux
kernel. PaX prevents executable memory pages from being
overwritten by injected machine code and thus prevents exploitation
of common security vulnerabilities, such as buffer overflows.
December 2014
Document # 331648-001
Intel® IoT Gateway - Security Profiles
Whitepaper
9
Security Features of Intel® IoT Gateway
2.2.1
GRSecurity Administration Utility (gradm)
The GRSecurity Administration Utility helps manage the RBAC system. gradm
parses access control lists (ACLs), enforces a secure base policy, and
optimizes the ACLs. It also parses the learning logs from full learning mode,
merges them with your ACL set, and outputs the final ACLs.
2.2.2
GRSecurity Full Learning Mode
The GRSecurity full learning mode is used to generate policy files for new
packages that you want to deploy.
2.2.3
RBAC Policies Using Full System Learning Mode
GRSecurity's learning mode can be used on a per-subject, per-role basis, or
system-wide. The learning mode can learn all things that the RBAC system
supports: files, capabilities, resources, the IP addresses that use each role,
and socket usage.
To enable full system learning, run the following as root:
# gradm -F -L /etc/grsec/learning.logs
This enables the RBAC system and initiates full system learning. gradm
monitors and logs your system’s activities. You can use the log to build a
least privilege policy for your system.
It is important to run and use your normal applications several times.
This is important because the learning mode uses a threshold–based system
to determine when access should be given to a file or whether it should be
given to a directory.
NOTE:
GRSecurity features aid in reducing commonly found software vulnerabilities,
such as address space layout randomization, supervisory mode access and
execution, and exploitation in brute force attacks.
For a complete description of GRSecurity, including installation and setup
steps, see the Wind River Intelligent Device Platform Programmer’s Guide.
Intel® IoT Gateway - Security Profiles
Whitepaper
10
December 2014
Document # 331648-001
Security Features of Intel® IoT Gateway
2.3
McAfee* Embedded Control
McAfee Embedded Control for Wind River includes a McAfee layer that allows
you to configure McAfee embedded products to use them on a Wind River
target platform. McAfee Embedded Control provides McAfee Application
Control McAfee Change Control to the Wind River Linux target platforms:
McAfee Embedded Control is a single solution that provides system integrity
and change control for embedded devices. This software blocks unauthorized
applications from running on your embedded systems. McAfee Application
Control/Application whitelisting has the capability to allow only authorized
code to run and prevent any code other than whitelisted code to run.
The Dynamic update provided by whitelist is capable of restricting updates
from a trusted channel. These are called authorized updaters. Application
Control offers a tamper proof feature to guard against attacks to the
whitelisted system components.
The McAfee Change Control mechanism offers an end-to-end compliance
solution by providing file integrity monitoring and change prevention. It
provides an integrity monitoring service policy driven real-time visibility of
change events on the endpoints, and it provides the capability to restrict
system changes and provide the ability to monitor the file system.
McAfee Embedded Control effectively provides the whitelisting feature that
secures the image of allowable agents/applications for a specific device.
For a complete description, and installation and setup steps, see the Wind
River Intelligent Device Platform Programmer’s Guide.
December 2014
Document # 331648-001
Intel® IoT Gateway - Security Profiles
Whitepaper
11
Security Features of Intel® IoT Gateway
Figure 2.
McAfee Embedded Control Overview
Whitelist enumerates the set of programs that are allowed to run on the host
computer. The members of the whitelist are called authorized or solidified
program code. Any program not in the whitelist is considered unauthorized.
Its execution is prevented, and the failure to execute is logged.
Figure 3.
Whitelisting Process
Intel® IoT Gateway - Security Profiles
Whitepaper
12
December 2014
Document # 331648-001
Security Features of Intel® IoT Gateway
2.4
Integrity Measurement Architecture (IMA)
The Integrity Measurement Architecture provides the capability for a system
to perform appraisals to prevent unauthorized/unsigned loading of
applications and libraries. IMA ensures application integrity through a tamperproof file system. The tamper-proof file system prevents end users from
making modifications to the device software and from executing unauthorized
applications on the device.
The tamper-proof file system prevents unauthorized executable applications
from running on the device, while it allows authorized software providers to
deploy their applications to the device, where the applications can run without
exceptions.
The following hooks are implemented in integrity management:
•
IMA Appraisal verifies the extended attribute security.ima of the
file against the file SHA1 digest. security.ima must contain an RSA
digital signature signed by a recognized RSA private key.
•
EVM Digest verifies the extended attribute security.evm of the file
against the file SHA1 digest. security.evm must contain an HMAC
cipher encrypted by a recognized EVM key.
•
EVM Digital Signature verifies the extended attribute security.evm
against the HMAC value calculated by the EVM digest. security.evm
must contain an RSA digital signature signed by a recognized RSA
private key.
For a complete description, including installation and setup steps, see the
Wind River Intelligent Device Platform Programmer’s Guide.
December 2014
Document # 331648-001
Intel® IoT Gateway - Security Profiles
Whitepaper
13
Security Profiles for Intel® IoT Gateway
3
Security Profiles for Intel® IoT Gateway
As described in Section 2 several security features are provided within Intel®
IoT Gateway to meet various security objectives. You can choose any
combination of these and configure your product to achieve different security
goals.
This section illustrates combinations of security features that comprise a preOS and post-OS structure.
To offer end-to-end security protection, you can combine a pre-OS security
feature with a post-OS security feature. You can use Secure Boot to provide
protection against boot tamper attempts as boot verification, up to the
verification of OS image integrity. Combining GRSecurity, McAfee Embedded
Control, and IMA is offer post system boot protection, to the application,
kernel, OS and system level.
The following table illustrates the possible security profiles configuration in
the Intel® IoT Gateway products.
Table 2.
Pre-OS and Post-OS protections
Pre-OS
Secure Boot
Intel® IoT Gateway - Security Profiles
Whitepaper
14
Post-OS
Primary Security Objectives
GRSecurity
RBAC and memory protection
McAfee
Embedded
Control
Whitelisting; Prevent non-approved SW from execution;
Change Monitoring & Prevention
IMA
Integrity protection
GRSecurity +
McAfee
Embedded
Control
RBAC, memory protection and whitelisting application +
control + change monitoring & prevention
GRSecurity +
IMA
RBAC, memory protection, file signing and file integrity
protection.
December 2014
Document # 331648-001
Security Profiles for Intel® IoT Gateway
3.1
Secure Boot
Secure Boot provides security protection at the pre-OS area by providing
mechanisms to verify the authenticity and integrity of the software before it is
loaded and run. Secure Boot protection can be combined with post-OS boot
levels of security features such as GRSecurity, McAfee Embedded Control or
IMA.
For information about configuring Secure Boot, see the documentation listed
in Table 1.
3.2
Secure Boot with GRSecurity and McAfee Embedded
Control
You must define the GRSecurity RBAC policy for software to work correctly.
This section describes the workflow to enable McAfee Embedded Control with
GRSecurity RBAC, using GRSecurity full learning mode. This generates a
minimal working policy required for McAfee Embedded Control to work with
GRSecurity RBAC.
3.2.1
Workflow to Enable GRSecurity and McAfee Embedded
Control
Use the following workflows to derive the GRSecurity policy and with McAfee
Embedded Control:
1. Setup the master password:
# gradm –P
Input and confirm your password.
2. Set up the password for role shutdown:
# gradm –P shutdown
Input and confirm your password.
3. Enable GRSecurity in full learning mode:
# gradm -F -L /etc/grsec/learning.logs
December 2014
Document # 331648-001
Intel® IoT Gateway - Security Profiles
Whitepaper
15
Security Profiles for Intel® IoT Gateway
4. Generate McAfee Embedded Control white list:
# sadmin so
5. Enable McAfee Embedded Control:
# sadmin enable
6. Restart McAfee Embedded Control service to for McAfee Embedded
Control to get into Enable state:
# /etc/init.d/scsrvc restart
7. Define any required McAfee Embedded Control polices (updaters, read
protection, write protection, monitoring)
8. Run /usr/local/mcafee/solidcore/tools/gatherinfo/gatherinfo.sh
to make the GRSecurity RBAC learn about the McAfee Embedded Control
tool.
Define the CLI password
# sadmin password
9. Repeat steps 4 to 8 for two to three times.
10. Generate polices from learning mode.
# gradm -F -L /etc/grsec/learning.logs –O /etc/grsec/policy
11. Exit learning mode
# gradm –D
12. Use the policies generated above to enable GRSecurity.
# gradmn -E
Intel® IoT Gateway - Security Profiles
Whitepaper
16
December 2014
Document # 331648-001
Security Profiles for Intel® IoT Gateway
Policies generated from GRSecurity learning mode might require small
modifications to generate a full working policy. If the policy does not work,
see Section 3.2.1.1, Known Issues and Resolutions, for guidance and then try
again.
3.2.1.1
Known Issues and Resolutions
Issue: “sadmin so” failed to write whitelist (inventory)
scsrvc might be denied access to write the inventory.
Resolution: “sadmin so” failed to write whitelist (inventory)
Review the GRSecurity RBAC log for failures. If necessary, run dmesg to
locate the GRSecurity failure logs. Add a rule to give the McAfee Embedded
Control scsrvc permissions for the .solidcore directory in the volume in
which the denial occurred. Use the following steps.
1. Disable GRSecurity:
# gradm –D
2. Search for subject /usr/local/mcafee/solidcore/bin/scsrvc in the
GRSecurity policy file.
3. Under subject /usr/local/mcafee/solidcore/bin/scsrvc
4. In the policy file, provide read/write access in the McAfee Embedded
Control directory that holds the whitelist. To do so add the following:
/.solidcore rwcd
The section for subject /usr/local/mcafee/solidcore/bin/scsrvc
should now look like this:
subject /usr/local/mcafee/solidcore/bin/scsrvc o {
/
December 2014
Document # 331648-001
/.solidcore
rwcd
/.solidcore/scinv
rwcd
/.solidcore/scinv.tmp
rwcd
/.solidcore/scinvlog
wc
Intel® IoT Gateway - Security Profiles
Whitepaper
17
Security Profiles for Intel® IoT Gateway
5. Enable GRSecurity:
# gradm –E
Issue: McAfee Embedded Control service restart failed
scsrvc might be denied access to the McAfee Embedded Control configuration
file.
Resolution: McAfee Embedded Control service restart failed
Analyze the GRSecurity RBAC log for failures. Make sure McAfee Embedded
Control service scsrvc has required privileges to read and write to the
configuration file /etc/mcafee/solidcore/solidcore.conf and to
/etc/mcafee/solidcore/solidcore.conf.tmp. Use the following steps:
6. Disable GRSecurity:
# gradm –D
7. Search for subject /usr/local/mcafee/solidcore/bin/scsrvc in the
GRSecurity policy file.
8. Under subject /usr/local/mcafee/solidcore/bin/scsrvc, provide
read/write access to subject scsrvc in the McAfee Embedded Control
directory that holds the whitelist. To do so add the following.
/etc/mcafee/solidcore/solidcore.conf
rwcd
/etc/mcafee/solidcore/solidcore.conf.tmp
rwcd
The subject /usr/local/mcafee/solidcore/bin/scsrvc section should
now look like this.
Intel® IoT Gateway - Security Profiles
Whitepaper
18
December 2014
Document # 331648-001
Security Profiles for Intel® IoT Gateway
subject /usr/local/mcafee/solidcore/bin/scsrvc o {
/
/.solidcore
rwcd
/.solidcore/scinv
rwcd
/.solidcore/scinv.tmp
rwcd
/.solidcore/scinvlog
wc
/etc/mcafee/solidcore/solidcore.conf
rwcd
/etc/mcafee/solidcore/solidcore.conf.tmp
rwcd
9. Enable GRSecurity.
# gradm –E
3.3
Secure Boot with GRSecurity and IMA
This section provides workflows to enable the IMA within the GRSecurity
RBAC policy. This is used when you want to define a GRSecurity RBAC policy
for software that works correctly within the GRSecurity environment. To
define a policy set for IMA to work with GRSecurity, use the GRSecurity full
learning mode feature.
Before beginning this workflow, obtain a list of commands you will need to
execute after the targets boots up. This is necessary because GRSecurity is
taking a least working privilege approach. After you enable this GRSecurity
policy, the system will only allow execution of the commands that are excuted
during the learning process. Other commands will be denied access.
3.3.1
Workflow to Enable GRSecurity and IMA
Use the following workflow to generate the GRSecrity RBAC policy.
1. Prepare a shell script that contains all the commands you would want to
execute after the target boots up. In this example, the name used is
effective_cmd.sh
2. Set up the GRSecurity master password:
# gradm –P
Follow the screen instruction to input and confirm the password.
December 2014
Document # 331648-001
Intel® IoT Gateway - Security Profiles
Whitepaper
19
Security Profiles for Intel® IoT Gateway
3. Set up the password for role shutdown instruction:
# gradm –P shutdown
Input and confirm your password.
4. Enable the GRSecurity in full learning mode
# gradm -F -L /root/learning.logs
5. Run effective_cmd.sh three times:
# sh effective_cmd.sh
# sh effective_cmd.sh
# sh effective_cmd.sh
6. Exit learning mode:
# gradm –D
Input your master password.
7. Generate policy from learning logs:
# gradm -F -L /root/learning.logs –O /etc/grsec/policy
8. Edit /etc/grsec/policy to make it compatible with the process
ima_digsig_daemon.sh which is automatically started. Replace:
# Role: root
subject /usr/bin/setfattr o {
……
……
}
with
Intel® IoT Gateway - Security Profiles
Whitepaper
20
December 2014
Document # 331648-001
Security Profiles for Intel® IoT Gateway
# Role: root
subject /usr/bin/setfattr o {
/
h
/bin
w
/etc
rw
/etc/grsec
h
/etc/gshadow
h
/etc/gshadow-
h
/etc/passwd
h
/etc/samba/smbpasswd h
/etc/shadow
h
/etc/shadow-
h
/etc/ssh
h
/lib
rxw
/lib/modules
h
/opt
h
/opt/benchmark
w
/opt/lmbench
w
/opt/ltp
w
/opt/open_posix_testsuite
/opt/prosyst_osgi
w
/opt/testsuite
w
/root
w
/sbin
w
/usr
h
/usr/bin
xw
/usr/lib
w
/usr/libexec
w
/usr/sbin
w
/usr/share
w
/www
w
w
-CAP_ALL
+CAP_SYS_ADMIN
bind
disabled
connect
disabled
}
December 2014
Document # 331648-001
Intel® IoT Gateway - Security Profiles
Whitepaper
21
Security Profiles for Intel® IoT Gateway
NOTE:
The ingredients in step 8 enable IMA signing learning within the GRSecurity
structure. The contents of effective_cmd.sh in step#5 are not directly
related to step#8. Step#8 is the key to maintain GRSecurity and IMA
execution in harmony.
9. Enable GRSecurity with the policy you just generated:
# gradm –E
If the policy does not work, see Section 3.3.2.1,Known Issues and Solutions,
for guidance and then try again.
3.3.2
PaX
GRSecurity provides memory protection via PaX, It flags data memory,
the stack, for example, as non-executable and program memory as nonwritable. This prevents memory from being overwritten, which can help to
prevent many types of security vulnerabilities, such as buffer overflows. PaX
also provides Address Space Layout Randomization (ASLR), which randomizes
important memory addresses to reduce the chances of attacks that rely on
easily predicted memory addresses.
Once the GRSecurity is included in your project, PaX will take effect. There is
no special command to turn on the PaX feature; it takes effect when
GRSecurity is started. If you do not want to include the PaX feature, you can
exclude it with the option –-with-template = feature/non_grsec
Intel® IoT Gateway - Security Profiles
Whitepaper
22
December 2014
Document # 331648-001
Security Profiles for Intel® IoT Gateway
The default kernel configuration for PaX is:
CONFIG_PAX=y
# CONFIG_PAX_SOFTMODE is not set
CONFIG_PAX_EI_PAX=y
CONFIG_PAX_PT_PAX_FLAGS=y
CONFIG_PAX_XATTR_PAX_FLAGS=y
# CONFIG_PAX_NO_ACL_FLAGS is not set
CONFIG_PAX_HAVE_ACL_FLAGS=y
# CONFIG_PAX_HOOK_ACL_FLAGS is not set
CONFIG_PAX_NOEXEC=y
CONFIG_PAX_PAGEEXEC=y
CONFIG_PAX_SEGMEXEC=y
# CONFIG_PAX_EMUTRAMP is not set
CONFIG_PAX_MPROTECT=y
CONFIG_PAX_MPROTECT_ALLOW_PTRACE=y
# CONFIG_PAX_MPROTECT_COMPAT is not set
# CONFIG_PAX_ELFRELOCS is not set
# CONFIG_PAX_KERNEXEC is not set
CONFIG_PAX_KERNEXEC_PLUGIN_METHOD=""
CONFIG_PAX_ASLR=y
CONFIG_PAX_RANDKSTACK=y
CONFIG_PAX_RANDUSTACK=y
CONFIG_PAX_RANDMMAP=y
# CONFIG_PAX_MEMORY_SANITIZE is not set
# CONFIG_PAX_MEMORY_STACKLEAK is not set
# CONFIG_PAX_MEMORY_UDEREF is not set
CONFIG_PAX_REFCOUNT=y
CONFIG_PAX_USERCOPY=y
CONFIG_PAX_SIZE_OVERFLOW=y
You can change the default PaX configurations in your kernel configuration.
You can also change the flags for specified files via the paxctl tool. Type
paxctl –help for information.
December 2014
Document # 331648-001
Intel® IoT Gateway - Security Profiles
Whitepaper
23
Security Profiles for Intel® IoT Gateway
To best demonstrate the GRSecurity PaX feature, two sample programs are
provided to show a case buffer overflow scenario. The sample source code is
in Appendix A, Sample PaX Usage. Below are the specific instructions to
exhibit the buffer overflow protection:
1. Build source code on a host:
$ gcc a.c
$ sudo chown root:sys a.out
$ sudo chmod 4555 a.out
$ gcc attack.c -o attack
2. Copy the executable files to target:
scp a.out ./attack root@targetIP:/root/
3. Copy private key from your project to target:
scp Proj_dir/wr-srm/files/keys/vendor-private.pem
root@targetIP:/root/
4. Sign the executable files on target:
evmctl ima_sign ./a.out ./vendor-private.pem
evmctl ima_sign ./attack ./vendor-private.pem
5. Execute the binary on target:
./attack
Intel® IoT Gateway - Security Profiles
Whitepaper
24
December 2014
Document # 331648-001
Security Profiles for Intel® IoT Gateway
6. On a system with GRSecurity (PaX) enabled, the execution will be killed
and the following information will display on the screen:
root@WR-IntelligentDevice:~# ./attack
[98281.168774] grsec: denied RWX mmap of /ttt by
/root/a.out[a.out:21949] uid/euid:0/0 gid/egid:0/0, parent
/bin/bash[sh:2432] uid/euid:0/0 gid/egid:0/0
[98281.186584] grsec: Segmentation fault occurred at ffffffff in
/root/a.out[a.out:21949] uid/euid:0/0 gid/egid:0/0, parent
/bin/bash[sh:2432] uid/euid:0/0 gid/egid:0/0
[98281.207027] grsec: denied resource overstep by requesting
4096 for RLIMIT_CORE against limit 0 for
/root/a.out[a.out:21949] uid/euid:0/0 gid/egid:0/0, parent
/bin/bash[sh:2430
Segmentation fault
root@WR-IntelligentDevice:~#
On a system that does not have PaX enabled, the execution will run without
problems.
3.3.2.1
Known Issues and Solutions
Problem: Read access
root@WR-IntelligentDevice:~# gradm -E
Read access to /lib/modules is allowed by the root role. This is the directory
that holds kernel modules. The ability to read these images provides an
attacker with useful information for launching "ret-to-libc" style attacks
against the kernel.
One hole was found in your RBAC configuration. This must be fixed before the
RBAC system can be enabled.
December 2014
Document # 331648-001
Intel® IoT Gateway - Security Profiles
Whitepaper
25
Security Profiles for Intel® IoT Gateway
Solution: Read access
Add the variable $grsec_denied to that role, as follows:
1. Before the line -CAP_ALL in the policy, add the line $grsec_denied
2. If items are pre-defined in the $grsec_denied list, comment them out, as
shown in the sample below.
3. Save and re-enable the policy.
role root uG
role_transitions admin shutdown
role_allow_ip …/32
# Role: root
subject /
{
….
# /lib/modules h
# /lib64/modules h
…..
$grsec_denied
-CAP_ALL
bind
disabled
connect
disabled
}
Intel® IoT Gateway - Security Profiles
Whitepaper
26
December 2014
Document # 331648-001
Security Profiles for Intel® IoT Gateway
Problem: Write access
root@WR-IntelligentDevice:~# gradm -E
Write access is allowed by role default to /etc. This directory holds
initialization scripts and configuration files.
One hole was found in your RBAC configuration. This must be fixed before the
RBAC system can be enabled.
Solution: Write access
Edit the /etc/grsec/policy to remove the write privilege w for /etc
Role default
Subject / {
…
/etc rw
Problem: Denied connection
You may be see the following error displayed when the system is in the
Enable state:
[ 4029.203301] grsec: (daemon:U:/sbin/portmap) denied connect()
to 128.224.159.155 port 42442 sock type dgram protocol udp by
/sbin/portmap[portmap:2208] uid/euid:1/1 gid/egid:10
[ 4039.066393] grsec: (daemon:U:/sbin/portmap) denied connect()
to 128.224.159.246 port 56898 sock type dgram protocol udp by
/sbin/portmap[portmap:2208] uid/euid:1/1 gid/egid:10
December 2014
Document # 331648-001
Intel® IoT Gateway - Security Profiles
Whitepaper
27
Security Profiles for Intel® IoT Gateway
Solution: Denied connection
Modify /etc/grsec/policy to replace:
# Role: daemon
subject /sbin/portmap o {
……
……
}
With
# Role: daemon
subject /sbin/portmap o {
/
h
-CAP_ALL
bind
disabled
connect 128.224.159.155/32:1024-65535 dgram udp
connect 128.224.159.246/32:1024-65535 dgram udp
}
NOTE:
The IP address above will be different in your environment.
Intel® IoT Gateway - Security Profiles
Whitepaper
28
December 2014
Document # 331648-001
Summary
4
Summary
With an Intel® IoT Gateway product you have rich security options to design
the gateway product in accordance to your needs. Depending on the security
objectives of the gateway product, you have options to protect you gateway
in the pre-OS and post-OS capacity.
For pre-OS, you can use the Secure Boot feature to safeguard the boot
sequences from BIOS to the point before booting the operating system.
Post-OS, you can choose a combination of security features of GRSecurity,
McAfee Embedded Control, and IMA. Depending on your security objectives,
the gateway products can choose from:
•
A standalone post-OS security attribute of GRSecurity, McAfee
Embedded Control, or IMA
•
A combination of GRSecurity with McAfee Embedded Control
•
GRSecurity with IMA
When a combined security option is chosen, you must note the known
configuration issues of the configuration to maintain system stability.
December 2014
Document # 331648-001
Intel® IoT Gateway - Security Profiles
Whitepaper
29
Summary
Appendix A Sample PaX Usage
Two PaX samples follow: a.c and attack.c
A.1
Sample a.c File
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
void (*ptr)(void);
int main(int argc,char *argv[])
{
int fd;
char *buf;
fd = open("/ttt", O_RDWR|O_CREAT, S_IRWXU|S_IRWXG|S_IRWXO);
write (fd, "helloworld", 10);
buf = mmap(NULL, 256, PROT_EXEC|PROT_READ|PROT_WRITE,
MAP_SHARED, fd, 0);
strcpy(buf, argv[1]);
printf ("buf = %p\n", buf);
ptr = (void (*)(void))(buf + 16);
printf ("ptr = %p\n", ptr);
ptr();
munmap(buf, 256);
close(fd);
return 0;
}
Intel® IoT Gateway - Security Profiles
Whitepaper
30
December 2014
Document # 331648-001
Summary
A.2
Sample attack.c File
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
char shellcode[] = "\x31\xdb\x89\xd8\xb0\x17\xcd\x80" /*
setuid(0) */
"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c"
"\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb"
"\x89\xd8\x40\xcd\x80\xe8\xdc\xff\xff\xff/bin/sh";
int main(void)
{
char *arg[3];
char *buf = malloc(256);
memset(buf, 0x90, 256);
memcpy(buf+32, shellcode, sizeof(shellcode));
buf[255]=0;
arg[0]="./a.out";
arg[1]=buf;
arg[2]=NULL;
execve(arg[0],arg,NULL);
return 0;
}
December 2014
Document # 331648-001
Intel® IoT Gateway - Security Profiles
Whitepaper
31
Summary
Appendix B Questions and Answers
B.1
Both IMA and McAfee Embedded Control are
configured and enabled, but IMA is blocking my file
or process
When both IMA and McAfee Embedded Control are configured, IMA hooks
have first consideration. McAfee Embedded Control hooks sit at the
application layer. Therefore, the denial is from IMA.
The McAfee Embedded Control denial check comes after IMA, so only in the
following case will McAfee Embedded Control deny execution when co-existing
with IMA: If the respective binary contains a signed checksum in file attribute
referred by IMA for deny exec, but is not whitelisted.
B.2
Why are symbolic links removable in McAfee
Embedded Control even though whitelisted?
The /bin/rm command in Wind River Linux is a symbolic link. Symbolic links
are not whitelisted, and therefore they are not tamper proof. Only binaries
and scripts are whitelisted and hence tamper proof.
If you want to make symbolic links or any other unsupported files (files which
are not whitelisted) tamper proof, you can add write protection rules for them
and protect them.
sadmin wp -i /bin/rm
root@WR-IntelligentDevice:/bin# mv rm myrm
U.1348.1423: Oct 30 2014:10:04:44.354:
ERROR: evt.c: 1240:
McAfee Solidifier prevented an attempt to modify file '/bin/rm'
by process /bin/mv.coreutils (Process Id: 6292, User: root)
Intel® IoT Gateway - Security Profiles
Whitepaper
32
December 2014
Document # 331648-001
© Copyright 2024 ExpyDoc
