Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 09 9月, 2014 2 次提交
  3. 03 9月, 2014 4 次提交
  5. 02 9月, 2014 1 次提交
  7. 05 8月, 2014 1 次提交
  9. 03 8月, 2014 1 次提交
  11. 02 8月, 2014 1 次提交
  13. 01 8月, 2014 4 次提交
    • P
      netlabel: shorter names for the NetLabel catmap funcs/structs · 4fbe63d1
      由 Paul Moore 提交于 
      Historically the NetLabel LSM secattr catmap functions and data
structures have had very long names which makes a mess of the NetLabel
code and anyone who uses NetLabel.  This patch renames the catmap
functions and structures from "*_secattr_catmap_*" to just "*_catmap_*"
which improves things greatly.

There are no substantial code or logic changes in this patch.
Signed-off-by: NPaul Moore <pmoore@redhat.com>
Tested-by: NCasey Schaufler <casey@schaufler-ca.com>
      4fbe63d1
    • P
      netlabel: fix the catmap walking functions · d960a618
      由 Paul Moore 提交于 
      The two NetLabel LSM secattr catmap walk functions didn't handle
certain edge conditions correctly, causing incorrect security labels
to be generated in some cases.  This patch corrects these problems and
converts the functions to use the new _netlbl_secattr_catmap_getnode()
function in order to reduce the amount of repeated code.

Cc: stable@vger.kernel.org
Signed-off-by: NPaul Moore <pmoore@redhat.com>
Tested-by: NCasey Schaufler <casey@schaufler-ca.com>
      d960a618
    • P
      netlabel: fix the horribly broken catmap functions · 4b8feff2
      由 Paul Moore 提交于 
      The NetLabel secattr catmap functions, and the SELinux import/export
glue routines, were broken in many horrible ways and the SELinux glue
code fiddled with the NetLabel catmap structures in ways that we
probably shouldn't allow.  At some point this "worked", but that was
likely due to a bit of dumb luck and sub-par testing (both inflicted
by yours truly).  This patch corrects these problems by basically
gutting the code in favor of something less obtuse and restoring the
NetLabel abstractions in the SELinux catmap glue code.

Everything is working now, and if it decides to break itself in the
future this code will be much easier to debug than the code it
replaces.

One noteworthy side effect of the changes is that it is no longer
necessary to allocate a NetLabel catmap before calling one of the
NetLabel APIs to set a bit in the catmap.  NetLabel will automatically
allocate the catmap nodes when needed, resulting in less allocations
when the lowest bit is greater than 255 and less code in the LSMs.

Cc: stable@vger.kernel.org
Reported-by: NChristian Evans <frodox@zoho.com>
Signed-off-by: NPaul Moore <pmoore@redhat.com>
Tested-by: NCasey Schaufler <casey@schaufler-ca.com>
      4b8feff2
    • P
      netlabel: fix a problem when setting bits below the previously lowest bit · 41c3bd20
      由 Paul Moore 提交于 
      The NetLabel category (catmap) functions have a problem in that they
assume categories will be set in an increasing manner, e.g. the next
category set will always be larger than the last.  Unfortunately, this
is not a valid assumption and could result in problems when attempting
to set categories less than the startbit in the lowest catmap node.
In some cases kernel panics and other nasties can result.

This patch corrects the problem by checking for this and allocating a
new catmap node instance and placing it at the front of the list.

Cc: stable@vger.kernel.org
Reported-by: NChristian Evans <frodox@zoho.com>
Signed-off-by: NPaul Moore <pmoore@redhat.com>
Tested-by: NCasey Schaufler <casey@schaufler-ca.com>
      41c3bd20
  15. 31 7月, 2014 1 次提交
  17. 30 7月, 2014 5 次提交
  19. 29 7月, 2014 2 次提交
  21. 28 7月, 2014 4 次提交
  23. 26 7月, 2014 5 次提交
  25. 25 7月, 2014 1 次提交
  27. 24 7月, 2014 3 次提交
    • E
      CAPABILITIES: remove undefined caps from all processes · 7d8b6c63
      由 Eric Paris 提交于 
      This is effectively a revert of 7b9a7ec5
plus fixing it a different way...

We found, when trying to run an application from an application which
had dropped privs that the kernel does security checks on undefined
capability bits.  This was ESPECIALLY difficult to debug as those
undefined bits are hidden from /proc/$PID/status.

Consider a root application which drops all capabilities from ALL 4
capability sets.  We assume, since the application is going to set
eff/perm/inh from an array that it will clear not only the defined caps
less than CAP_LAST_CAP, but also the higher 28ish bits which are
undefined future capabilities.

The BSET gets cleared differently.  Instead it is cleared one bit at a
time.  The problem here is that in security/commoncap.c::cap_task_prctl()
we actually check the validity of a capability being read.  So any task
which attempts to 'read all things set in bset' followed by 'unset all
things set in bset' will not even attempt to unset the undefined bits
higher than CAP_LAST_CAP.

So the 'parent' will look something like:
CapInh:	0000000000000000
CapPrm:	0000000000000000
CapEff:	0000000000000000
CapBnd:	ffffffc000000000

All of this 'should' be fine.  Given that these are undefined bits that
aren't supposed to have anything to do with permissions.  But they do...

So lets now consider a task which cleared the eff/perm/inh completely
and cleared all of the valid caps in the bset (but not the invalid caps
it couldn't read out of the kernel).  We know that this is exactly what
the libcap-ng library does and what the go capabilities library does.
They both leave you in that above situation if you try to clear all of
you capapabilities from all 4 sets.  If that root task calls execve()
the child task will pick up all caps not blocked by the bset.  The bset
however does not block bits higher than CAP_LAST_CAP.  So now the child
task has bits in eff which are not in the parent.  These are
'meaningless' undefined bits, but still bits which the parent doesn't
have.

The problem is now in cred_cap_issubset() (or any operation which does a
subset test) as the child, while a subset for valid cap bits, is not a
subset for invalid cap bits!  So now we set durring commit creds that
the child is not dumpable.  Given it is 'more priv' than its parent.  It
also means the parent cannot ptrace the child and other stupidity.

The solution here:
1) stop hiding capability bits in status
	This makes debugging easier!

2) stop giving any task undefined capability bits.  it's simple, it you
don't put those invalid bits in CAP_FULL_SET you won't get them in init
and you won't get them in any other task either.
	This fixes the cap_issubset() tests and resulting fallout (which
	made the init task in a docker container untraceable among other
	things)

3) mask out undefined bits when sys_capset() is called as it might use
~0, ~0 to denote 'all capabilities' for backward/forward compatibility.
	This lets 'capsh --caps="all=eip" -- -c /bin/bash' run.

4) mask out undefined bit when we read a file capability off of disk as
again likely all bits are set in the xattr for forward/backward
compatibility.
	This lets 'setcap all+pe /bin/bash; /bin/bash' run
Signed-off-by: NEric Paris <eparis@redhat.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Cc: Andrew Vagin <avagin@openvz.org>
Cc: Andrew G. Morgan <morgan@kernel.org>
Cc: Serge E. Hallyn <serge.hallyn@canonical.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Steve Grubb <sgrubb@redhat.com>
Cc: Dan Walsh <dwalsh@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      7d8b6c63
    • J
      Merge tag 'keys-next-20140722' of... · 4ca332e1
      由 James Morris 提交于 
      Merge tag 'keys-next-20140722' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs into next
      4ca332e1
    • T
      commoncap: don't alloc the credential unless needed in cap_task_prctl · 6d6f3328
      由 Tetsuo Handa 提交于 
      In function cap_task_prctl(), we would allocate a credential
unconditionally and then check if we support the requested function.
If not we would release this credential with abort_creds() by using
RCU method. But on some archs such as powerpc, the sys_prctl is heavily
used to get/set the floating point exception mode. So the unnecessary
allocating/releasing of credential not only introduce runtime overhead
but also do cause OOM due to the RCU implementation.

This patch removes abort_creds() from cap_task_prctl() by calling
prepare_creds() only when we need to modify it.
Reported-by: NKevin Hao <haokexin@gmail.com>
Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Reviewed-by: NPaul Moore <paul@paul-moore.com>
Acked-by: NSerge E. Hallyn <serge.hallyn@ubuntu.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      6d6f3328
  29. 23 7月, 2014 5 次提交
    • D
      Merge branch 'keys-fixes' into keys-next · 633706a2
      由 David Howells 提交于 
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      633706a2
    • D
      Merge remote-tracking branch 'integrity/next-with-keys' into keys-next · 64724cfc
      由 David Howells 提交于 
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      64724cfc
    • D
      Merge tag 'keys-pefile-20140709' into keys-next · 6204e002
      由 David Howells 提交于 
      Here's a set of changes that implement a PE file signature checker.

This provides the following facility:

 (1) Extract the signature from the PE file.  This is a PKCS#7 message
     containing, as its data, a hash of the signed parts of the file.

 (2) Digest the signed parts of the file.

 (3) Compare the digest with the one from the PKCS#7 message.

 (4) Validate the signatures on the PKCS#7 message and indicate
     whether it was matched by a trusted key.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
      6204e002
    • D
      Merge tag 'keys-pkcs7-20140708' into keys-next · 1ca72c96
      由 David Howells 提交于 
      Here's a set of changes that implement a PKCS#7 message parser in the kernel.

The PKCS#7 message parsing will then be used to limit kexec to authenticated
kernels only if so configured.

The changes provide the following facilities:

 (1) Parse an ASN.1 PKCS#7 message and pick out useful bits such as the data
     content and the X.509 certificates used to sign it and all the data
     signatures.

 (2) Verify all the data signatures against the set of X.509 certificates
     available in the message.

 (3) Follow the certificate chains and verify that:

     (a) for every self-signed X.509 certificate, check that it validly signed
     	 itself, and:

     (b) for every non-self-signed certificate, if we have a 'parent'
     	 certificate, the former is validly signed by the latter.

 (4) Look for intersections between the certificate chains and the trusted
     keyring, if any intersections are found, verify that the trusted
     certificates signed the intersection point in the chain.

 (5) For testing purposes, a key type can be made available that will take a
     PKCS#7 message, check that the message is trustworthy, and if so, add its
     data content into the key.

Note that (5) has to be altered to take account of the preparsing patches
already committed to this branch.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
      1ca72c96
    • D
      Merge tag 'keys-preparse-1-20140722' into keys-next · a19e3c22
      由 David Howells 提交于 
      Here are a set of changes that make all but encrypted and trusted keys use
preparsing.  Unfortunately, encrypted and trusted keys incorrectly use the
update op to alter a key, so other changes will need to be made for them.

These changes permit payload parsing when instantiating or updating a key to be
done before locks are taken and to determine the amount of quota that will be
required in advance.  The latter will make it possible to do LRU discard before
any locks are taken.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
      a19e3c22