Re: user guide draft: "Targeted Policy" review

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Daniel J Walsh wrote:
Murray McAllister wrote:
Daniel J Walsh wrote:
Murray McAllister wrote:
Hi,

The following is a draft of the "Targeted Policy" sections for the
SELinux User Guide. Any comments and corrections are appreciated.

Thanks.

Targeted Policy

Targeted policy is the default SELinux policy used in Fedora 10. When
using targeted policy, subjects that are targeted run in their own
domain type, and subjects that are not targeted run in the unconfined_t
confined domain, and subjects that are not targeted run in an unconfined
domain,  For example logged in users by default log in as unconfined_t
while system processes started by init run in initrc_t.  Both of these
domains are unconfined.

NOTE:

Even unconfined domains are subject to executable/writable memory
checks.  execmem, execstack, execheap.  By default processes run as an
unconfined domain can not allocate writeable memory and execute it.
This is a common attack vector call buffer overflow attacks.  Some
applications require this type of access (java, wine, mono and a few
others).
Does this mean applications running in a Java Virtual Machine, and in Wine?
I'll change my response below based on the answer to this.
Yes
These applications need to be labeled correctly to allow the
access.  There are booleans that can turn off this protection for the
unconfined user unconfined_t.  allow_execmem, allow_execstack,
allow_execheap.

You can turn the booleans on using setsebool

setsebool -P allow_execmem 1

I will use these examples later on.

How about:
Targeted policy is the default SELinux policy used in Fedora 10. When
using targeted policy, subjects that are targeted run in a confined
domain, and subjects that are not targeted run in an unconfined domain.
For example, by default, logged in users run in the unconfined_t domain,
and system processes started by init run in the initrc_t domain - both
of these domains are unconfined.
Unconfined domains (as well as confined domains) are subject to
executable and writeable memory checks. By default, subjects running in
an unconfined domain can not allocate writeable memory and execute it.
[I think I changed the meaning. Is it still correct? ]
Looks good
This reduces vulnerability to buffer overflow attacks. Some subjects
require this access, including but not limited to Java", Wine and Mono.
To allow this access, these subjects must be labeled correctly.

For example, if you had a java application /usr/local/bin/myjavaapp,
that was not working because it needed the execmem access, you could
change the system labeling.
# semanage fcontext -a -t java_exec_t /usr/local/bin/myjavaapp
Then you fix the context on the actual file
# restorecon /usr/local/bin/myjavaapp

myjavaapp will now be allowed to run with execmem and execstack.

If you do not want to deal with any of the memory checks for users, you
can disable them with by setting the allow_exec* booleans.

# setsebool -P allow_execmem=1 allow_execstack=1 allow_execheap=1
You can check if the booleans current state by executing

getsebool -a | grep allow_exec

You system is most protected if these booleans are turned off.

# setsebool -P allow_execmem=0 allow_execstack=0 allow_execheap=0

memory checks need to be disabled for the users running in the
unconfined_t domain.
No this sentence is wrong.
These memory checks are disable by setting
booleans, which allow the SELinux policy to be modified during runtime.
Configuring booleans is discussed later.


I removed some bits to avoid too much theory:

Unconfined domains (as well as confined domains) are subject to executable and writeable memory checks. By default, subjects running in an unconfined domain can not allocate writeable memory and execute it. This reduces vulnerability to buffer overflow attacks. These memory checks are disable by setting booleans, which allow the SELinux policy to be modified during runtime. Configuring booleans is discussed later.

How about:
When an unconfined subject is comprised, SELinux does not prevent the
attacker from gaining access to system resources and data, and DAC rules
are used.
(I should probably change these to "If an...")
If an unconfined subject is comprised, SELinux does not prevent the
attacker from gaining access to system resources and data, of course DAC
rules are used.

Note: A common misconception about SELinux is that it replaces DAC
Controls, when it really just augments them.

How about:

If an unconfined subject is compromised, SELinux does not prevent the attacker from gaining access to system resources and data, but of course, DAC rules are still used. SELinux is a security enhancement on top of DAC rules - it does not replace them.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.

[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux