http://slashdot.jp/linux/article.pl?sid=09/07/22/0121226

この脆弱性であるが、Linuxにおいてはユーザプロセスが0番地にmmap()することが合法だったので
ユーザ空間のデーモンなどにも大穴があいていた。
んで、そもそもなんで０番地mmapなんかする必要があるんだーーという議論になり、vm86では必要とか
そんな議論に。
で、一時互換性重要派閥が勝利しかけたんだけど、Linus裁定により、特殊なpersonalityを持つプロセス以外０番地mmap()できなくなったはず。

うろ覚えで書いているから、まったく間違っているかもしれない。


まあ、ようするにgccの仮定がセキュリティ視点からはナンセンス極まりなかった。とそういうイージーな問題。


追記：なんか、Eric Parisがうだうだ言ってたので貼っとく。
ようするに、SELinuxをONにするとセキュリティが弱くなるってどうよ？ってことかね。

Subject: mmap_min_addr and your local LSM (ok, just SELinux)
From Eric Paris <eparis@redhat.com>

Brad Spengler recently pointed out that the SELinux decision on how to
handle mmap_min_addr in some ways weakens system security vs on a system
without SELinux (and in other ways can be stronger). There is a trade
off and a reason I did what I did but I would like ideas and discussion
on how to get the best of both worlds.

With SELinux mapping the 0 page requires an SELinux policy permission,
mmap_zero. Without SELinux mapping the 0 page requires CAP_SYS_RAWIO.
Note that CAP_SYS_RAWIO roughly translates to uid=0 since noone really
does interesting things with capabilities.

The main problem is WINE. I'm told that WINE needs to map the 0 page to
support 16bit applications. On distros without SELinux users must
disable the mmap_min_addr protections for the ENTIRE system if they want
to run WINE.

http://wiki.winehq.org/PreloaderPageZeroProblem

I believe (from reading mailing lists) if you install WINE on ubuntu it
automatically disables these protections. Thus installing wine on
ubuntu disables ALL hardening gains of the mmap_min_addr.

On Fedora, with SELinux, we allow users to run WINE in a domain that has
the SELinux mmap_zero permission and thus other programs/domains, do not
have security weakened. Your daemons, like the web server, are still
unable to map the 0 page. This is different than distros without
SELinux, remember they have to disable protection globally.

But logged in users (by default), under SELinux, are 'unconfined' and
can by their very nature run their program in a domain that allows
mmap_zero. Trying to 'confine' the 'unconfined' user with SELinux is an
open problem which we don't currently even reasonably attempt address on
a broad scale. It's like besieging the user in a gentle mist of water
hoping they won't try to escape.

So in Fedora your web server is a harder entry point to exploit kernel
NULL pointer bugs, but you have no protections against a malicious user.
On Ubuntu if you install WINE your web server and your logged in users
have no hardening. If you do not install WINE non-root is hardened,
anything running as root is not (aka suid apps, aka pulseaudio).

So I was thinking today, wondering how to get the best (or at least
better) of both worlds on an SELinux system. I was considering adding a
second mmap_min_addr_lsm which would typically be equal to
mmap_min_addr. The purpose would be to allow the sysadmin to
individually control DAC/LSM protections. The security checks would
turn (sort of) into

if (addr < mmap_min_addr)
ret |= capable(CAP_SYS_RAWIO);
if (addr < mmap_min_addr_lsm)
ret |= [insert LSM check here]

So on a non-SELinux system users would end up with exactly what they
have today. if you want to run WINE as a normal user you have to set
mmap_min_addr = 0 and then you no longer need CAP_SYS_RAWIO. Not much
else we can do if your distro down support fine grained permissions.

On an SELinux system what this lets me do is default to a stricter
setup, one in which you have to have both CAP_SYS_RAWIO and the selinux
mmap_zero permission. You, out of the box, get protection for both your
malicious logged in user and your web server. Then if a user decides to
run WINE they would turn down mmap_min_addr. This would remove the
requirement that they are root, and leave the system vulnerable to a
malicious user, but would still allow SELinux to protect confined
domains and daemons.

Does anyone see a better way to let users continue to be users while
protecting most people? Yes SELinux is stronger in some areas than
without confining the ability to map the 0 page, but as has be rightly
pointed out it's foolish an broken that SELinux can weaken any
protections.

-Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

それに対する、James Morrisからの返答

I haven't seen a better idea so far.

I strongly believe that we need to maintain the principle, in SELinux and
LSM generally, that the interface is restrictive, i.e. that it can only
further restrict access. It should be impossible, from a design point of
view at least, for any LSM module to authorize more privilege than
standard DAC. This has always been a specific design goal of LSM. (The
capability module is an exception, as it has a fixed security policy and
implements legacy DAC behavior; there's no way to "fix" this).

In this case, we're not dealing with a standard form of access control,
where access to a userland object is being mediated. We're trying to
mediate the ability of a subject to bypass a separate mechanism which aims
to protect the kernel itself from attack via a more fundamental system
flaw. The LSM module didn't create that vulnerability directly, but it
must not allow the vulnerability to be more easily exploited.

The security policy writer should have a guarantee that the worst mistake
they can make is to mess up their own security model; if they can mess up
the base DAC security with MAC policy, we break that guarantee. There's
also an issue of user confidence in the LSM modules, in that they should
not be any worse off security-wise if they enable an enhanced protection
mechanism.

This does not account for kernel bugs in the LSM modules themselves,
obviously, but the same can be said for any kernel code, albeit with less
irony.

そのあと、Eric Parisが出してきたパッチ

その１： CONFIG_SECURIYの有無にかかわらず、常にCAP_SYS_RAWIOをチェックするように変更

Subject: [PATCH 1/2] VM/SELinux: require CAP_SYS_RAWIO for all mmap_zero operations



Currently non-SELinux systems need CAP_SYS_RAWIO for an application to mmap

the 0 page.  On SELinux systems they need a specific SELinux permission,

but do not need CAP_SYS_RAWIO.  This has proved to be a poor decision by

the SELinux team as, by default, SELinux users are logged in unconfined and

thus a malicious non-root has nothing stopping them from mapping the 0 page

of virtual memory.



On a non-SELinux system, a malicious non-root user is unable to do this, as

they need CAP_SYS_RAWIO.



This patch checks CAP_SYS_RAWIO for all operations which attemt to map a

page below mmap_min_addr.



Signed-off-by: Eric Paris 

---



 include/linux/security.h |    2 --

 mm/mmap.c                |   10 ++++++++++

 mm/mremap.c              |    8 ++++++++

 mm/nommu.c               |    3 +++

 security/capability.c    |    2 --

 5 files changed, 21 insertions(+), 4 deletions(-)



diff --git a/include/linux/security.h b/include/linux/security.h

index 1459091..f7d198a 100644

--- a/include/linux/security.h

+++ b/include/linux/security.h

@@ -2197,8 +2197,6 @@ static inline int security_file_mmap(struct file *file, unsigned long reqprot,

 				     unsigned long addr,

 				     unsigned long addr_only)

 {

-	if ((addr < mmap_min_addr) && !capable(CAP_SYS_RAWIO))

-		return -EACCES;

 	return 0;

 }

 

diff --git a/mm/mmap.c b/mm/mmap.c

index 34579b2..37fdc90 100644

--- a/mm/mmap.c

+++ b/mm/mmap.c

@@ -1047,6 +1047,9 @@ unsigned long do_mmap_pgoff(struct file *file, unsigned long addr,

 		}

 	}

 

+	if ((addr < mmap_min_addr) && !capable(CAP_SYS_RAWIO))

+		return -EACCES;

+

 	error = security_file_mmap(file, reqprot, prot, flags, addr, 0);

 	if (error)

 		return error;

@@ -1657,6 +1660,10 @@ static int expand_downwards(struct vm_area_struct *vma,

 		return -ENOMEM;

 

 	address &= PAGE_MASK;

+

+	if ((address < mmap_min_addr) && !capable(CAP_SYS_RAWIO))

+		return -EACCES;

+

 	error = security_file_mmap(NULL, 0, 0, 0, address, 1);

 	if (error)

 		return error;

@@ -1998,6 +2005,9 @@ unsigned long do_brk(unsigned long addr, unsigned long len)

 	if (is_hugepage_only_range(mm, addr, len))

 		return -EINVAL;

 

+	if ((addr < mmap_min_addr) && !capable(CAP_SYS_RAWIO))

+		return -EACCES;

+

 	error = security_file_mmap(NULL, 0, 0, 0, addr, 1);

 	if (error)

 		return error;

diff --git a/mm/mremap.c b/mm/mremap.c

index a39b7b9..066e73d 100644

--- a/mm/mremap.c

+++ b/mm/mremap.c

@@ -299,6 +299,10 @@ unsigned long do_mremap(unsigned long addr,

 		if ((addr <= new_addr) && (addr+old_len) > new_addr)

 			goto out;

 

+		ret = -EACCES;

+		if ((new_addr < mmap_min_addr) && !capable(CAP_SYS_RAWIO))

+			goto out;

+

 		ret = security_file_mmap(NULL, 0, 0, 0, new_addr, 1);

 		if (ret)

 			goto out;

@@ -407,6 +411,10 @@ unsigned long do_mremap(unsigned long addr,

 				goto out;

 			}

 

+			ret = -EACCES;

+			if ((new_addr < mmap_min_addr) && !capable(CAP_SYS_RAWIO))

+				goto out;

+

 			ret = security_file_mmap(NULL, 0, 0, 0, new_addr, 1);

 			if (ret)

 				goto out;

diff --git a/mm/nommu.c b/mm/nommu.c

index 53cab10..c1f3eff 100644

--- a/mm/nommu.c

+++ b/mm/nommu.c

@@ -995,6 +995,9 @@ static int validate_mmap_request(struct file *file,

 	}

 

 	/* allow the security API to have its say */

+	if ((addr < mmap_min_addr) && !capable(CAP_SYS_RAWIO))

+		return -EACCES;

+

 	ret = security_file_mmap(file, reqprot, prot, flags, addr, 0);

 	if (ret < 0)

 		return ret;

diff --git a/security/capability.c b/security/capability.c

index f218dd3..a3a5d9b 100644

--- a/security/capability.c

+++ b/security/capability.c

@@ -334,8 +334,6 @@ static int cap_file_mmap(struct file *file, unsigned long reqprot,

 			 unsigned long prot, unsigned long flags,

 			 unsigned long addr, unsigned long addr_only)

 {

-	if ((addr < mmap_min_addr) && !capable(CAP_SYS_RAWIO))

-		return -EACCES;

 	return 0;

 }

 



--

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

the body of a message to majordomo@vger.kernel.org

More majordomo info at  http://vger.kernel.org/majordomo-info.html

Please read the FAQ at  http://www.tux.org/lkml/

その２： selinux_file_mmapがmmap_min_addrチューニングパラメタを無視して、常に０ページを
チェックするようにする。
つまり、mmap_min_addr=0でSELinuxのチェックを無効化できなくするパッチ。

Subject: [PATCH 2/2] SELinux: selinux_file_mmap always enforce mapping the 0 page



Currently SELinux enforcement of controls on the ability to map the 0 page

is determined by the mmap_min_addr tunable.  This patch causes SELinux to

ignore the tunable and to always (but ONLY) protect the 0 page.



The tunable will now only control the need for CAP_SYS_RAWIO and SELinux

permissions will always protect the 0 page based on it's mmap_zero

permission.



This allows users who need to disable the mmap_min_addr controls (usual reason

being they run WINE as a non-root user) to do so and still have SELinux

controls preventing confined domains (like a web server) from being able to

map the 0 page.



Note: the additional SELinux restriction will now ONLY protect the 0 page.

CAP_SYS_RAWIO will protect anything between 0 and mmap_min_addr, but SELinux

will only protect between 0 and PAGE_SIZE.



Signed-off-by: Eric Paris 

---



 include/linux/security.h |    1 -

 security/selinux/hooks.c |    2 +-

 2 files changed, 1 insertions(+), 2 deletions(-)



diff --git a/include/linux/security.h b/include/linux/security.h

index f7d198a..de774f7 100644

--- a/include/linux/security.h

+++ b/include/linux/security.h

@@ -91,7 +91,6 @@ struct seq_file;

 extern int cap_netlink_send(struct sock *sk, struct sk_buff *skb);

 extern int cap_netlink_recv(struct sk_buff *skb, int cap);

 

-extern unsigned long mmap_min_addr;

 /*

  * Values used in the task_security_ops calls

  */

diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c

index e65677d..7bbac1d 100644

--- a/security/selinux/hooks.c

+++ b/security/selinux/hooks.c

@@ -3034,7 +3034,7 @@ static int selinux_file_mmap(struct file *file, unsigned long reqprot,

 	int rc = 0;

 	u32 sid = current_sid();

 

-	if (addr < mmap_min_addr)

+	if (addr < PAGE_SIZE)

 		rc = avc_has_perm(sid, sid, SECCLASS_MEMPROTECT,

 				  MEMPROTECT__MMAP_ZERO, NULL);

 	if (rc || addr_only)



--

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

the body of a message to majordomo@vger.kernel.org

More majordomo info at  http://vger.kernel.org/majordomo-info.html

Please read the FAQ at  http://www.tux.org/lkml/