[PATCH] iio hid-sensor-trigger: add Kconfig depends on IIO_BUFFER

[Alexander Wuerstlein]

Building a kernel with my configuration failed with:
> drivers/built-in.o: In function `hid_sensor_setup_batch_mode': 
> staging/drivers/iio/common/hid-sensors/hid-sensor-trigger.c:104: undefined 
> reference to `iio_buffer_set_attrs'
which is fixed by this patch.

Signed-off-by: Alexander Wuerstlein <a...@arw.name>
---
 drivers/iio/common/hid-sensors/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/common/hid-sensors/Kconfig 
b/drivers/iio/common/hid-sensors/Kconfig
index 39188b72cd3b..80105378b0ba 100644
--- a/drivers/iio/common/hid-sensors/Kconfig
+++ b/drivers/iio/common/hid-sensors/Kconfig
@@ -16,7 +16,7 @@ config HID_SENSOR_IIO_COMMON
 
 config HID_SENSOR_IIO_TRIGGER
tristate "Common module (trigger) for all HID Sensor IIO drivers"
-   depends on HID_SENSOR_HUB && HID_SENSOR_IIO_COMMON
+   depends on HID_SENSOR_HUB && HID_SENSOR_IIO_COMMON && IIO_BUFFER
select IIO_TRIGGER
help
  Say yes here to build trigger support for HID sensors.
-- 
2.11.0

[PATCH] iio hid-sensor-trigger: add Kconfig depends on IIO_BUFFER

[Alexander Wuerstlein]

Building a kernel with my configuration failed with:
> drivers/built-in.o: In function `hid_sensor_setup_batch_mode': 
> staging/drivers/iio/common/hid-sensors/hid-sensor-trigger.c:104: undefined 
> reference to `iio_buffer_set_attrs'
which is fixed by this patch.

Signed-off-by: Alexander Wuerstlein 
---
 drivers/iio/common/hid-sensors/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/common/hid-sensors/Kconfig 
b/drivers/iio/common/hid-sensors/Kconfig
index 39188b72cd3b..80105378b0ba 100644
--- a/drivers/iio/common/hid-sensors/Kconfig
+++ b/drivers/iio/common/hid-sensors/Kconfig
@@ -16,7 +16,7 @@ config HID_SENSOR_IIO_COMMON
 
 config HID_SENSOR_IIO_TRIGGER
tristate "Common module (trigger) for all HID Sensor IIO drivers"
-   depends on HID_SENSOR_HUB && HID_SENSOR_IIO_COMMON
+   depends on HID_SENSOR_HUB && HID_SENSOR_IIO_COMMON && IIO_BUFFER
select IIO_TRIGGER
help
  Say yes here to build trigger support for HID sensors.
-- 
2.11.0

Re: [i4passt] [PATCH 1/4] Documentation/misc-devices/mei: Fix formatting of headings.

[Alexander Wuerstlein]

On 2015-01-28T20:17, Jonathan Corbet  wrote:
> On Mon, 12 Jan 2015 00:58:06 +0100
> Julian Brost  wrote:
> 
> > Make the heading underlines fit the length of the heading, remove colons
> > at the end of headings and consistently place an empty line after each
> > heading and two empty lines before each that is preceded by a paragraph.
> > 
> > Signed-off-by: Julian Brost 
> > Signed-off-by: Fabian Hofmann 
> 
> [Finally catching up with stuff after a long travel]
> 
> These changes look fine, but what's with the two signoffs?  Who is the
> actual author of these patches, and why is the second signoff there?

I'm not an author of this patch, but I can explain that: Julian and
Fabian are students of mine and as part of classwork they are supposed
to submit a patch to the linux kernel. Since we require our students to
work in groups of two and to collaborate on producing and submitting the
patch, we also strongly urge them to submit with two signed-off-by-lines
to properly attribute the patch to both students.

I hope this doesn't cause any confusion or misbehaving tools or
anything.

If you are interested in further information on the course you can visit
https://www4.cs.fau.de/Lehre/WS14/P_PASST/ (unfortunately only in
german) or ask me by email. There is also a (not up-to-date for this
semester) list of previously accepted patches that were produced in
earlier iterations of this course:
https://www4.cs.fau.de/Lehre/WS14/P_PASST/kernel-commits-all.shtml


Greetings,

Alexander Wuerstlein.


Alexander Wuerstlein Informatik 4Univ. of Erlangen
Martensstrasse 191058 Erlangen   +49-9131-85-27824
a...@arw.name  a...@cs.fau.de   3CD3D074014E217A745FC4A34E2CCA53C746347D
snalw...@cip.cs.fau.de https://www4.cs.fau.de/~arw
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [i4passt] [PATCH 1/4] Documentation/misc-devices/mei: Fix formatting of headings.

[Alexander Wuerstlein]

On 2015-01-28T20:17, Jonathan Corbet cor...@lwn.net wrote:
 On Mon, 12 Jan 2015 00:58:06 +0100
 Julian Brost linux-ker...@0x4a42.net wrote:
 
  Make the heading underlines fit the length of the heading, remove colons
  at the end of headings and consistently place an empty line after each
  heading and two empty lines before each that is preceded by a paragraph.
  
  Signed-off-by: Julian Brost linux-ker...@0x4a42.net
  Signed-off-by: Fabian Hofmann fabian.hofm...@fau.de
 
 [Finally catching up with stuff after a long travel]
 
 These changes look fine, but what's with the two signoffs?  Who is the
 actual author of these patches, and why is the second signoff there?

I'm not an author of this patch, but I can explain that: Julian and
Fabian are students of mine and as part of classwork they are supposed
to submit a patch to the linux kernel. Since we require our students to
work in groups of two and to collaborate on producing and submitting the
patch, we also strongly urge them to submit with two signed-off-by-lines
to properly attribute the patch to both students.

I hope this doesn't cause any confusion or misbehaving tools or
anything.

If you are interested in further information on the course you can visit
https://www4.cs.fau.de/Lehre/WS14/P_PASST/ (unfortunately only in
german) or ask me by email. There is also a (not up-to-date for this
semester) list of previously accepted patches that were produced in
earlier iterations of this course:
https://www4.cs.fau.de/Lehre/WS14/P_PASST/kernel-commits-all.shtml


Greetings,

Alexander Wuerstlein.


Alexander Wuerstlein Informatik 4Univ. of Erlangen
Martensstrasse 191058 Erlangen   +49-9131-85-27824
a...@arw.name  a...@cs.fau.de   3CD3D074014E217A745FC4A34E2CCA53C746347D
snalw...@cip.cs.fau.de https://www4.cs.fau.de/~arw
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Check files' signatures before doing suid/sgid [2/4]

[Alexander Wuerstlein]

On 070626 01:56, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> On 6/25/07, Alexander Wuerstlein
> <[EMAIL PROTECTED]> wrote:
>> On 070622 21:40, Satyam Sharma <[EMAIL PROTECTED]> wrote:
>> > [...]
>> We decided against
>> altering the file itself for that and some other reasons.
>> The limitation to suid/sgid was only due to a limited amount of time we 
>> had for
>> implementing our patch. For the future we are planning further uses like
>> setting capabilities only for signed binaries.
>
> Ok, effectively what you have there is a signature on an entire file stored
> in one of its extended attributes, so I suspect you could think of few other
> applications for something like this too.

Yes, for example one could sign Java's classfiles and employ a special trusted
Java VM which checks the signatures before execution. Also, this is a more
general case of signing kernel modules (as you mentioned below). There are
really numerous applications one could imagine, we just don't really know which
ones are practical. We definitely appreciate further ideas on this.

Also the signature-in-ELF can be used complementary to our approach: for
example NFS is currently unable to handle real extended attributes (nfs does
only posix acls). So for binaries delivered over NFS our approach wouldn't
work.

> Ok, so:
>
> 1. Admin is trusted. [ This need not mean the same as: "superuser
> _account_ is trusted", but let's stay in the real world in for now. ]
> 2. Signing happens at some central, assumed-to-be-secure location (and say
> the private key never leaves that central secure location). And let's say the
> admin *repackages* the packages, this time such that the signed files get the
> signature-carrying-extended-attributes with them, so the installation
> automatically copies them correctly. => nothing wrong with this assumption.
> 3. Kernel verifies signatures at runtime. => kernel is trusted.
> 4. Public key needs to be *compiled into* the kernel ... so this is not 
> getting into mainline, but fair enough as something site administrators would
> patch in and build.

Correct up to here.

> 5. Chain-of-trust handled in userspace. => userspace is trusted.

Nope. I unluckily wrote 'userspace' where I should have said something else:
Chain-of-trust is handled in what I would label 'Adminspace' (Where we do the
signing as in points 1 and 2). There is a very small number of signatures (in
our example one) known to the kernel and only those are trusted, and those are
applied to the binaries by the administrator in your point 2. The kernel does
and should never rely on userspace to tell it which signatures are trustworthy.
Only the administrator may do so by means of the signatures directly compiled
into the kernel.

So in short: Chain-of-trust is handled by the administrator in his secure
central location.

>> So far for the initial idea. Perhaps it would be useful to have more than 
>> one
>> key or some more complex scheme for obtaining the keys and checking their
>> validity.  But as all of this would need to be part of the kernel we 
>> decided to
>> rather keep it as simple as possible, anything complex is better and more
>> flexibly done in userspace.
>
> Well, if you're trusting (privileged) userspace already, I'm suddenly not so
> sure as to what new is this patchset bringing to the table in the first place
> ...

We do not trust any userspace application, see above.

> could you also describe the attack vectors / threats that you had in mind
> that get blocked with the proposed scheme?

We focus on attacks where an attacker may alter some executable file, for
example by altering a mounted nfs-share, manipulating disk-content by simply
pulling a disk, mounting it and writing to it, etc.

This relies on the kernel beeing trustworthy of course, so one would need to
take special measures to protect the kernel-image from beeing similarly
altered. One (somewhat not-so-secure method) would be supplying kernel images
by PXE and forbidding local booting, another measure would be using a TPM
and an appropriate bootloader to check the kernel for unwanted modifications.

> Have a look at modsign (signed kernel modules) project too (just the key
> management part, specifically the asymmetric crypto and DSA implementation
> that they've already ported to the kernel). You could also go through the 
> lkml archives for whenever that was proposed for inclusion in mainline ...

We already thought about that. Using some existing code is definitely preferable
to inventing DSA again :)



Ciao,

Alexander Wuerstlein.


pgpqh98zrD0Th.pgp
Description: PGP signature

Re: [PATCH] Check files' signatures before doing suid/sgid [2/4]

[Alexander Wuerstlein]

On 070626 01:56, Satyam Sharma [EMAIL PROTECTED] wrote:
 On 6/25/07, Alexander Wuerstlein
 [EMAIL PROTECTED] wrote:
 On 070622 21:40, Satyam Sharma [EMAIL PROTECTED] wrote:
  [...]
 We decided against
 altering the file itself for that and some other reasons.
 The limitation to suid/sgid was only due to a limited amount of time we 
 had for
 implementing our patch. For the future we are planning further uses like
 setting capabilities only for signed binaries.

 Ok, effectively what you have there is a signature on an entire file stored
 in one of its extended attributes, so I suspect you could think of few other
 applications for something like this too.

Yes, for example one could sign Java's classfiles and employ a special trusted
Java VM which checks the signatures before execution. Also, this is a more
general case of signing kernel modules (as you mentioned below). There are
really numerous applications one could imagine, we just don't really know which
ones are practical. We definitely appreciate further ideas on this.

Also the signature-in-ELF can be used complementary to our approach: for
example NFS is currently unable to handle real extended attributes (nfs does
only posix acls). So for binaries delivered over NFS our approach wouldn't
work.

 Ok, so:

 1. Admin is trusted. [ This need not mean the same as: superuser
 _account_ is trusted, but let's stay in the real world in for now. ]
 2. Signing happens at some central, assumed-to-be-secure location (and say
 the private key never leaves that central secure location). And let's say the
 admin *repackages* the packages, this time such that the signed files get the
 signature-carrying-extended-attributes with them, so the installation
 automatically copies them correctly. = nothing wrong with this assumption.
 3. Kernel verifies signatures at runtime. = kernel is trusted.
 4. Public key needs to be *compiled into* the kernel ... so this is not 
 getting into mainline, but fair enough as something site administrators would
 patch in and build.

Correct up to here.

 5. Chain-of-trust handled in userspace. = userspace is trusted.

Nope. I unluckily wrote 'userspace' where I should have said something else:
Chain-of-trust is handled in what I would label 'Adminspace' (Where we do the
signing as in points 1 and 2). There is a very small number of signatures (in
our example one) known to the kernel and only those are trusted, and those are
applied to the binaries by the administrator in your point 2. The kernel does
and should never rely on userspace to tell it which signatures are trustworthy.
Only the administrator may do so by means of the signatures directly compiled
into the kernel.

So in short: Chain-of-trust is handled by the administrator in his secure
central location.

 So far for the initial idea. Perhaps it would be useful to have more than 
 one
 key or some more complex scheme for obtaining the keys and checking their
 validity.  But as all of this would need to be part of the kernel we 
 decided to
 rather keep it as simple as possible, anything complex is better and more
 flexibly done in userspace.

 Well, if you're trusting (privileged) userspace already, I'm suddenly not so
 sure as to what new is this patchset bringing to the table in the first place
 ...

We do not trust any userspace application, see above.

 could you also describe the attack vectors / threats that you had in mind
 that get blocked with the proposed scheme?

We focus on attacks where an attacker may alter some executable file, for
example by altering a mounted nfs-share, manipulating disk-content by simply
pulling a disk, mounting it and writing to it, etc.

This relies on the kernel beeing trustworthy of course, so one would need to
take special measures to protect the kernel-image from beeing similarly
altered. One (somewhat not-so-secure method) would be supplying kernel images
by PXE and forbidding local booting, another measure would be using a TPM
and an appropriate bootloader to check the kernel for unwanted modifications.

 Have a look at modsign (signed kernel modules) project too (just the key
 management part, specifically the asymmetric crypto and DSA implementation
 that they've already ported to the kernel). You could also go through the 
 lkml archives for whenever that was proposed for inclusion in mainline ...

We already thought about that. Using some existing code is definitely preferable
to inventing DSA again :)



Ciao,

Alexander Wuerstlein.


pgpqh98zrD0Th.pgp
Description: PGP signature

Re: [PATCH] Check files' signatures before doing suid/sgid [2/4]

[Alexander Wuerstlein]

On 070622 21:40, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> Hi Alexander, Johannes,
>
> But first: Have you checked the digsig project? It's been doing
> (for some time) what your current patchset proposes -- and
> it uses public key cryptosystems for the key management,
> which is decidedly better than using secret-keyed hashes
> (HMAC, XCBC). Also, digsig aims to protect executable
> binaries in general, and not just suid / sgid ones.

We have not heard about digsig before, thanks for pointing it out. After a
short look over the source (correct me if I'm wrong): The most important
difference between our project and digsig is that digsig relies on storing
signatures inside the ELF file structure. Therefore a handmade binary-loader or
just COFF binaries could be used to circumvent digsig. We decided against
altering the file itself for that and some other reasons.

The limitation to suid/sgid was only due to a limited amount of time we had for
implementing our patch. For the future we are planning further uses like
setting capabilities only for signed binaries.

> Second: Can we have some discussion on the security model /
> threat model / trust model / cryptographic key management
> scheme of your signing mechanism? [I had read through the
> [0/4] mail you had sent yesterday, but found no relevant
> discussion on these aspects there.]

Our scenario was as follows: Usually system administrators rely on cronjobs
checking their binaries for unwanted suid-bits. Because of the obvious problems
with this (time between cronjobs, performance) we wrote our patch to replace it.

An admin would verify the to-be-installed binaries (e.g. by reading the source,
checking the distribution's package signatures), sign them in a central
location.  He then distributes those signatures along with the installation
packages onto his computers. There should only be one key in use at a site the
public part of which is compiled into the kernel. Any kind of chain-of-trust
should be handled in userspace by signing or not signing with the site-wide
key depending on the earlier signatures in the chain.

So far for the initial idea. Perhaps it would be useful to have more than one
key or some more complex scheme for obtaining the keys and checking their
validity.  But as all of this would need to be part of the kernel we decided to
rather keep it as simple as possible, anything complex is better and more
flexibly done in userspace.

> From the patchset, it appears you use a *common* secret key
> for _all_ signed binaries, and it is set at kernel build-time itself:
> [...]
> Anyway, this is *totally* insecure and broken. Do you realize anybody
> who lays hands on the kernel image can now _trivially_ extract the
> should-have-been-a-secret key from it and use it to sign his own
> binaries?

We do realize that this is really really ugly, broken and nasty and nobody
would or should ever want to use it for anything but playing around as it is
atm. ;)

We only used HMAC because it was already available inside the kernel, for
implementing real asymetric cryptography there was simply no time. Of course
our next objective is to implement that. 


Ciao,

Alexander Wuerstlein.


pgpFf6MgaeqbK.pgp
Description: PGP signature

Re: [PATCH] Check files' signatures before doing suid/sgid [2/4]

[Alexander Wuerstlein]

On 070622 21:40, Satyam Sharma [EMAIL PROTECTED] wrote:
 Hi Alexander, Johannes,

 But first: Have you checked the digsig project? It's been doing
 (for some time) what your current patchset proposes -- and
 it uses public key cryptosystems for the key management,
 which is decidedly better than using secret-keyed hashes
 (HMAC, XCBC). Also, digsig aims to protect executable
 binaries in general, and not just suid / sgid ones.

We have not heard about digsig before, thanks for pointing it out. After a
short look over the source (correct me if I'm wrong): The most important
difference between our project and digsig is that digsig relies on storing
signatures inside the ELF file structure. Therefore a handmade binary-loader or
just COFF binaries could be used to circumvent digsig. We decided against
altering the file itself for that and some other reasons.

The limitation to suid/sgid was only due to a limited amount of time we had for
implementing our patch. For the future we are planning further uses like
setting capabilities only for signed binaries.

 Second: Can we have some discussion on the security model /
 threat model / trust model / cryptographic key management
 scheme of your signing mechanism? [I had read through the
 [0/4] mail you had sent yesterday, but found no relevant
 discussion on these aspects there.]

Our scenario was as follows: Usually system administrators rely on cronjobs
checking their binaries for unwanted suid-bits. Because of the obvious problems
with this (time between cronjobs, performance) we wrote our patch to replace it.

An admin would verify the to-be-installed binaries (e.g. by reading the source,
checking the distribution's package signatures), sign them in a central
location.  He then distributes those signatures along with the installation
packages onto his computers. There should only be one key in use at a site the
public part of which is compiled into the kernel. Any kind of chain-of-trust
should be handled in userspace by signing or not signing with the site-wide
key depending on the earlier signatures in the chain.

So far for the initial idea. Perhaps it would be useful to have more than one
key or some more complex scheme for obtaining the keys and checking their
validity.  But as all of this would need to be part of the kernel we decided to
rather keep it as simple as possible, anything complex is better and more
flexibly done in userspace.

 From the patchset, it appears you use a *common* secret key
 for _all_ signed binaries, and it is set at kernel build-time itself:
 [...]
 Anyway, this is *totally* insecure and broken. Do you realize anybody
 who lays hands on the kernel image can now _trivially_ extract the
 should-have-been-a-secret key from it and use it to sign his own
 binaries?

We do realize that this is really really ugly, broken and nasty and nobody
would or should ever want to use it for anything but playing around as it is
atm. ;)

We only used HMAC because it was already available inside the kernel, for
implementing real asymetric cryptography there was simply no time. Of course
our next objective is to implement that. 


Ciao,

Alexander Wuerstlein.


pgpFf6MgaeqbK.pgp
Description: PGP signature

[PATCH] sns: add syscall to check signed state of a process [4/4]

[Alexander Wuerstlein]

Makes it possible for a userspace process to ask for the trustworthiness of
another process.

Signed-off-by: Johannes Schlumberger <[EMAIL PROTECTED]>
---
 arch/i386/kernel/syscall_table.S |1 +
 include/asm-i386/unistd.h|3 ++-
 security/sns.c   |   15 +++
 3 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/arch/i386/kernel/syscall_table.S b/arch/i386/kernel/syscall_table.S
index bf6adce..e8ba35a 100644
--- a/arch/i386/kernel/syscall_table.S
+++ b/arch/i386/kernel/syscall_table.S
@@ -323,3 +323,4 @@ ENTRY(sys_call_table)
.long sys_signalfd
.long sys_timerfd
.long sys_eventfd
+   .long sys_sns_is_trusted/* 320 */
diff --git a/include/asm-i386/unistd.h b/include/asm-i386/unistd.h
index e84ace1..3f8df3e 100644
--- a/include/asm-i386/unistd.h
+++ b/include/asm-i386/unistd.h
@@ -329,10 +329,11 @@
 #define __NR_signalfd  321
 #define __NR_timerfd   322
 #define __NR_eventfd   323
+#define __NR_sns_is_trusted324
 
 #ifdef __KERNEL__
 
-#define NR_syscalls 324
+#define NR_syscalls 325
 
 #define __ARCH_WANT_IPC_PARSE_VERSION
 #define __ARCH_WANT_OLD_READDIR
diff --git a/security/sns.c b/security/sns.c
index 3192a90..1978f7c 100644
--- a/security/sns.c
+++ b/security/sns.c
@@ -112,3 +112,18 @@ int sns_signature_valid(struct file *file)
crypto_free_hash(tfm);
return ret;
 }
+
+asmlinkage int sys_sns_is_trusted(pid_t p)
+{
+   struct task_struct *t;
+   rcu_read_lock();
+   t = find_task_by_pid(p);
+   if (IS_ERR(t)) {
+   rcu_read_unlock();
+   return -EINVAL;
+   }
+   p = t->sns_valid_sig; /*locking needed*/
+   rcu_read_unlock();
+   return p;
+}
+EXPORT_SYMBOL_GPL(sys_sns_is_trusted);
-- 
1.5.2.1

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

[PATCH] Check files' signatures before doing suid/sgid [2/4]

[Alexander Wuerstlein]

Modified task_struct to hold a 'signed flag' which is set on exec(), inherited
on fork() and checked during exec before giving the new process suid/sgid
privileges.

sns.c contains our helper functions to verify the signatures.
sns_secret_key.dat contains the 'secret key' which is used for HMAC.

Signed-off-by: Johannes Schlumberger <[EMAIL PROTECTED]>
---
 fs/exec.c   |   19 +++-
 include/linux/Kbuild|2 +
 include/linux/sched.h   |3 +
 include/linux/sns.h |3 +
 kernel/fork.c   |6 +++
 security/Kconfig|   28 
 security/Makefile   |1 +
 security/sns.c  |  104 +++
 security/sns_secret_key.dat |5 ++
 9 files changed, 169 insertions(+), 2 deletions(-)
 create mode 100644 include/linux/sns.h
 create mode 100644 security/sns.c
 create mode 100644 security/sns_secret_key.dat

diff --git a/fs/exec.c b/fs/exec.c
index f20561f..5dfa406 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -51,6 +51,9 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_SNS_SIGNED
+#include 
+#endif
 
 #include 
 #include 
@@ -928,13 +931,21 @@ int prepare_binprm(struct linux_binprm *bprm)
mode = inode->i_mode;
if (bprm->file->f_op == NULL)
return -EACCES;
+#ifdef CONFIG_SNS_SIGNED
+   if (mode & S_ISUID)
+   current->sns_valid_sig = sns_signature_valid(bprm->file);
+#endif
 
bprm->e_uid = current->euid;
bprm->e_gid = current->egid;
 
if(!(bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID)) {
/* Set-uid? */
-   if (mode & S_ISUID) {
+#ifdef CONFIG_SNS_SIGNED_SETUID
+   if (mode & S_ISUID && current->sns_valid_sig) {
+#else
+   if (mode & S_ISUID) {
+#endif /*SNS_SIGNED_SETUID*/
current->personality &= ~PER_CLEAR_ON_SETID;
bprm->e_uid = inode->i_uid;
}
@@ -945,7 +956,11 @@ int prepare_binprm(struct linux_binprm *bprm)
 * is a candidate for mandatory locking, not a setgid
 * executable.
 */
-   if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) {
+#ifdef CONFIG_SNS_SIGNED_SETGID
+   if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP) && 
current->sns_valid_sig) {
+#else
+   if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) {
+#endif /*SNS_SIGNED_SETGID*/
current->personality &= ~PER_CLEAR_ON_SETID;
bprm->e_gid = inode->i_gid;
}
diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index f317c27..16df5f0 100644
--- a/include/linux/Kbuild
+++ b/include/linux/Kbuild
@@ -159,6 +159,7 @@ header-y += videotext.h
 header-y += vt.h
 header-y += wireless.h
 header-y += x25.h
+header-y += sns.h
 
 unifdef-y += acct.h
 unifdef-y += adb.h
@@ -347,5 +348,6 @@ unifdef-y += watchdog.h
 unifdef-y += wireless.h
 unifdef-y += xattr.h
 unifdef-y += xfrm.h
+unifdef-y += sns.h
 
 objhdr-y += version.h
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 693f0e6..36c58d6 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1076,6 +1076,9 @@ struct task_struct {
 #ifdef CONFIG_FAULT_INJECTION
int make_it_fail;
 #endif
+#ifdef CONFIG_SNS_SIGNED
+   int sns_valid_sig;
+#endif
 };
 
 static inline pid_t process_group(struct task_struct *tsk)
diff --git a/include/linux/sns.h b/include/linux/sns.h
new file mode 100644
index 000..ad15e4b
--- /dev/null
+++ b/include/linux/sns.h
@@ -0,0 +1,3 @@
+#ifdef CONFIG_SNS_SIGNED
+int sns_signature_valid(struct file *);
+#endif
diff --git a/kernel/fork.c b/kernel/fork.c
index 73ad5cd..c12cf61 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -156,6 +156,9 @@ void __init fork_init(unsigned long mempages)
init_task.signal->rlim[RLIMIT_NPROC].rlim_max = max_threads/2;
init_task.signal->rlim[RLIMIT_SIGPENDING] =
init_task.signal->rlim[RLIMIT_NPROC];
+#ifdef CONFIG_SNS_SIGNED
+   init_task.sns_valid_sig = 0;
+#endif
 }
 
 static struct task_struct *dup_task_struct(struct task_struct *orig)
@@ -182,6 +185,9 @@ static struct task_struct *dup_task_struct(struct 
task_struct *orig)
 #ifdef CONFIG_CC_STACKPROTECTOR
tsk->stack_canary = get_random_int();
 #endif
+#ifdef CONFIG_SNS_SIGNED
+   tsk->sns_valid_sig = orig->sns_valid_sig;
+#endif
 
/* One for us, one for whoever does the "release_task()" (usually 
parent) */
atomic_set(>usage,2);
diff --git a/security/Kconfig b/security/Kconfig
index 460e5c9..bfaace7 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -4,6 +4,34 @@
 
 menu "Security options"
 
+config SNS_SIGNED
+   bool "Enable sns-signed binaries (EXPERIMENTAL)"
+   depends on (EXT2_FS_XATTR || EXT3_FS_XATTR || EXT4DEV_FS_XATTR || 
REISERFS_FS_XATTR || JFFS2_FS_XATTR || CIFS_XATTR) && (CRYPTO_SHA1 || 
CRYPTO_HMAC || 

[PATCH] sns: check related executable memory of binaries [3/4]

[Alexander Wuerstlein]

From: Johannes Schlumberger <[EMAIL PROTECTED]>

Checks on mmap and mprotect (i.e. libraries) wether they are signed and adjusts
the processe's signed flag accordingly.

If a process looses its signed state it gets, in our current design, killed, for
it is no longer trustworthy. A process also looses its signed flag if it 
mprotects
any memory as executable.

Signed-off-by: Johannes Schlumberger <[EMAIL PROTECTED]>
---
 include/linux/mm.h  |3 ++
 include/linux/sns.h |   17 +++
 kernel/fork.c   |7 
 mm/mmap.c   |   79 +++
 mm/mprotect.c   |   30 +++
 security/Kconfig|   36 +++
 security/sns.c  |   10 ++
 7 files changed, 176 insertions(+), 6 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index e4183c6..903bc45 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -112,6 +112,9 @@ struct vm_area_struct {
 #ifdef CONFIG_NUMA
struct mempolicy *vm_policy;/* NUMA policy for the VMA */
 #endif
+#ifdef CONFIG_SNS_SIGNED
+   int sns_valid_sig;
+#endif
 };
 
 extern struct kmem_cache *vm_area_cachep;
diff --git a/include/linux/sns.h b/include/linux/sns.h
index ad15e4b..eefb6e7 100644
--- a/include/linux/sns.h
+++ b/include/linux/sns.h
@@ -1,3 +1,20 @@
 #ifdef CONFIG_SNS_SIGNED
 int sns_signature_valid(struct file *);
+int sns_signature_becomes_invalid(void);
+
+/*
+ * The following is unfortunately necessary, there does not seem to be a
+ * common define to find out wether some ominous DSO which somebody
+ * likes to mmap or mprotect is in fact trustworthy kernel code.
+ */
+#ifdef CONFIG_X86
+#define sns_is_gate_vdso(addr, len) (addr==0xe000 && len == PAGE_SIZE)
+#else
+#ifdef CONFIG_IA64
+#define sns_is_gate_vdso(addr, len) (addr==0xe000UL && len == PAGE_SIZE)
+#else
+#define sns_is_gate_vdso(addr, len) 0
+#endif
+#endif
+
 #endif
diff --git a/kernel/fork.c b/kernel/fork.c
index c12cf61..b1afa57 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -260,6 +260,9 @@ static inline int dup_mmap(struct mm_struct *mm, struct 
mm_struct *oldmm)
file = tmp->vm_file;
if (file) {
struct inode *inode = file->f_path.dentry->d_inode;
+#ifdef CONFIG_SNS_SIGNED
+   tmp->sns_valid_sig = mpnt->sns_valid_sig;
+#endif
get_file(file);
if (tmp->vm_flags & VM_DENYWRITE)
atomic_dec(>i_writecount);
@@ -271,6 +274,10 @@ static inline int dup_mmap(struct mm_struct *mm, struct 
mm_struct *oldmm)
vma_prio_tree_add(tmp, mpnt);
flush_dcache_mmap_unlock(file->f_mapping);
spin_unlock(>f_mapping->i_mmap_lock);
+#ifdef CONFIG_SNS_SIGNED
+   } else {
+   tmp->sns_valid_sig = 0;
+#endif
}
 
/*
diff --git a/mm/mmap.c b/mm/mmap.c
index 68b9ad2..1f4bdf0 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -25,6 +25,9 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_SNS_SIGNED
+#include 
+#endif
 
 #include 
 #include 
@@ -1101,10 +1104,33 @@ munmap_back:
error = file->f_op->mmap(file, vma);
if (error)
goto unmap_and_free_vma;
-   } else if (vm_flags & VM_SHARED) {
-   error = shmem_zero_setup(vma);
-   if (error)
-   goto free_vma;
+#ifdef CONFIG_SNS_SIGNED
+   if (current->sns_valid_sig && (vm_flags & VM_EXEC)) {
+   if (vm_flags & VM_WRITE){
+   vma->sns_valid_sig = 0;
+   current->sns_valid_sig = 0;
+   sns_signature_becomes_invalid();
+   } else {
+   vma->sns_valid_sig = sns_signature_valid(file);
+   current->sns_valid_sig = vma->sns_valid_sig;
+   if(!current->sns_valid_sig)
+   sns_signature_becomes_invalid();
+   }
+   }
+#endif
+   } else {
+#ifdef CONFIG_SNS_SIGNED
+   /* JIT could have written some evil code here, which we are 
unable to verify */
+   if (prot & PROT_EXEC && current->sns_valid_sig) {
+   if ((vma->sns_valid_sig = (current->sns_valid_sig = 
(sns_is_gate_vdso(addr, len)
+   sns_signature_becomes_invalid();
+   }
+#endif
+   if (vm_flags & VM_SHARED) {
+   error = shmem_zero_setup(vma);
+   if (error)
+   goto free_vma;
+   }
}
 
/* We set VM_ACCOUNT in a shared mapping's vm_flags, to inform
@@ -1946,8 +1972,49 @@ unsigned long do_brk(unsigned long addr, unsigned long 
len)

[PATCH] export xattr_resolve_name_sns [1/4]

[Alexander Wuerstlein]

From: Johannes Schlumberger <[EMAIL PROTECTED]>

Makes it possible to get extended attributes for a given inode.  We need this
for cases where we no longer have the corresponding direntry.

Signed-off-by: Johannes Schlumberger <[EMAIL PROTECTED]>
---
 fs/xattr.c|   18 ++
 include/linux/xattr.h |1 +
 2 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/fs/xattr.c b/fs/xattr.c
index 4523aca..467417f 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -538,6 +538,24 @@ xattr_resolve_name(struct xattr_handler **handlers, const 
char **name)
return handler;
 }
 
+struct xattr_handler *
+xattr_resolve_name_sns(struct xattr_handler **handlers, const char **name)
+{
+   struct xattr_handler *handler;
+
+   if (!*name)
+   return NULL;
+
+   for_each_xattr_handler(handlers, handler) {
+   const char *n = strcmp_prefix(*name, handler->prefix);
+   if (n) {
+   *name = n;
+   break;
+   }
+   }
+   return handler;
+}
+
 /*
  * Find the handler for the prefix and dispatch its get() operation.
  */
diff --git a/include/linux/xattr.h b/include/linux/xattr.h
index def131a..5653508 100644
--- a/include/linux/xattr.h
+++ b/include/linux/xattr.h
@@ -46,6 +46,7 @@ struct xattr_handler {
   size_t size, int flags);
 };
 
+struct xattr_handler * xattr_resolve_name_sns(struct xattr_handler **, const 
char **);
 ssize_t vfs_getxattr(struct dentry *, char *, void *, size_t);
 ssize_t vfs_listxattr(struct dentry *d, char *list, size_t size);
 int vfs_setxattr(struct dentry *, char *, void *, size_t, int);
-- 
1.5.2.1

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

[PATCH] export xattr_resolve_name_sns [1/4]

[Alexander Wuerstlein]

From: Johannes Schlumberger [EMAIL PROTECTED]

Makes it possible to get extended attributes for a given inode.  We need this
for cases where we no longer have the corresponding direntry.

Signed-off-by: Johannes Schlumberger [EMAIL PROTECTED]
---
 fs/xattr.c|   18 ++
 include/linux/xattr.h |1 +
 2 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/fs/xattr.c b/fs/xattr.c
index 4523aca..467417f 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -538,6 +538,24 @@ xattr_resolve_name(struct xattr_handler **handlers, const 
char **name)
return handler;
 }
 
+struct xattr_handler *
+xattr_resolve_name_sns(struct xattr_handler **handlers, const char **name)
+{
+   struct xattr_handler *handler;
+
+   if (!*name)
+   return NULL;
+
+   for_each_xattr_handler(handlers, handler) {
+   const char *n = strcmp_prefix(*name, handler-prefix);
+   if (n) {
+   *name = n;
+   break;
+   }
+   }
+   return handler;
+}
+
 /*
  * Find the handler for the prefix and dispatch its get() operation.
  */
diff --git a/include/linux/xattr.h b/include/linux/xattr.h
index def131a..5653508 100644
--- a/include/linux/xattr.h
+++ b/include/linux/xattr.h
@@ -46,6 +46,7 @@ struct xattr_handler {
   size_t size, int flags);
 };
 
+struct xattr_handler * xattr_resolve_name_sns(struct xattr_handler **, const 
char **);
 ssize_t vfs_getxattr(struct dentry *, char *, void *, size_t);
 ssize_t vfs_listxattr(struct dentry *d, char *list, size_t size);
 int vfs_setxattr(struct dentry *, char *, void *, size_t, int);
-- 
1.5.2.1

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

[PATCH] Check files' signatures before doing suid/sgid [2/4]

[Alexander Wuerstlein]

Modified task_struct to hold a 'signed flag' which is set on exec(), inherited
on fork() and checked during exec before giving the new process suid/sgid
privileges.

sns.c contains our helper functions to verify the signatures.
sns_secret_key.dat contains the 'secret key' which is used for HMAC.

Signed-off-by: Johannes Schlumberger [EMAIL PROTECTED]
---
 fs/exec.c   |   19 +++-
 include/linux/Kbuild|2 +
 include/linux/sched.h   |3 +
 include/linux/sns.h |3 +
 kernel/fork.c   |6 +++
 security/Kconfig|   28 
 security/Makefile   |1 +
 security/sns.c  |  104 +++
 security/sns_secret_key.dat |5 ++
 9 files changed, 169 insertions(+), 2 deletions(-)
 create mode 100644 include/linux/sns.h
 create mode 100644 security/sns.c
 create mode 100644 security/sns_secret_key.dat

diff --git a/fs/exec.c b/fs/exec.c
index f20561f..5dfa406 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -51,6 +51,9 @@
 #include linux/cn_proc.h
 #include linux/audit.h
 #include linux/signalfd.h
+#ifdef CONFIG_SNS_SIGNED
+#include linux/sns.h
+#endif
 
 #include asm/uaccess.h
 #include asm/mmu_context.h
@@ -928,13 +931,21 @@ int prepare_binprm(struct linux_binprm *bprm)
mode = inode-i_mode;
if (bprm-file-f_op == NULL)
return -EACCES;
+#ifdef CONFIG_SNS_SIGNED
+   if (mode  S_ISUID)
+   current-sns_valid_sig = sns_signature_valid(bprm-file);
+#endif
 
bprm-e_uid = current-euid;
bprm-e_gid = current-egid;
 
if(!(bprm-file-f_path.mnt-mnt_flags  MNT_NOSUID)) {
/* Set-uid? */
-   if (mode  S_ISUID) {
+#ifdef CONFIG_SNS_SIGNED_SETUID
+   if (mode  S_ISUID  current-sns_valid_sig) {
+#else
+   if (mode  S_ISUID) {
+#endif /*SNS_SIGNED_SETUID*/
current-personality = ~PER_CLEAR_ON_SETID;
bprm-e_uid = inode-i_uid;
}
@@ -945,7 +956,11 @@ int prepare_binprm(struct linux_binprm *bprm)
 * is a candidate for mandatory locking, not a setgid
 * executable.
 */
-   if ((mode  (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) {
+#ifdef CONFIG_SNS_SIGNED_SETGID
+   if ((mode  (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)  
current-sns_valid_sig) {
+#else
+   if ((mode  (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) {
+#endif /*SNS_SIGNED_SETGID*/
current-personality = ~PER_CLEAR_ON_SETID;
bprm-e_gid = inode-i_gid;
}
diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index f317c27..16df5f0 100644
--- a/include/linux/Kbuild
+++ b/include/linux/Kbuild
@@ -159,6 +159,7 @@ header-y += videotext.h
 header-y += vt.h
 header-y += wireless.h
 header-y += x25.h
+header-y += sns.h
 
 unifdef-y += acct.h
 unifdef-y += adb.h
@@ -347,5 +348,6 @@ unifdef-y += watchdog.h
 unifdef-y += wireless.h
 unifdef-y += xattr.h
 unifdef-y += xfrm.h
+unifdef-y += sns.h
 
 objhdr-y += version.h
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 693f0e6..36c58d6 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1076,6 +1076,9 @@ struct task_struct {
 #ifdef CONFIG_FAULT_INJECTION
int make_it_fail;
 #endif
+#ifdef CONFIG_SNS_SIGNED
+   int sns_valid_sig;
+#endif
 };
 
 static inline pid_t process_group(struct task_struct *tsk)
diff --git a/include/linux/sns.h b/include/linux/sns.h
new file mode 100644
index 000..ad15e4b
--- /dev/null
+++ b/include/linux/sns.h
@@ -0,0 +1,3 @@
+#ifdef CONFIG_SNS_SIGNED
+int sns_signature_valid(struct file *);
+#endif
diff --git a/kernel/fork.c b/kernel/fork.c
index 73ad5cd..c12cf61 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -156,6 +156,9 @@ void __init fork_init(unsigned long mempages)
init_task.signal-rlim[RLIMIT_NPROC].rlim_max = max_threads/2;
init_task.signal-rlim[RLIMIT_SIGPENDING] =
init_task.signal-rlim[RLIMIT_NPROC];
+#ifdef CONFIG_SNS_SIGNED
+   init_task.sns_valid_sig = 0;
+#endif
 }
 
 static struct task_struct *dup_task_struct(struct task_struct *orig)
@@ -182,6 +185,9 @@ static struct task_struct *dup_task_struct(struct 
task_struct *orig)
 #ifdef CONFIG_CC_STACKPROTECTOR
tsk-stack_canary = get_random_int();
 #endif
+#ifdef CONFIG_SNS_SIGNED
+   tsk-sns_valid_sig = orig-sns_valid_sig;
+#endif
 
/* One for us, one for whoever does the release_task() (usually 
parent) */
atomic_set(tsk-usage,2);
diff --git a/security/Kconfig b/security/Kconfig
index 460e5c9..bfaace7 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -4,6 +4,34 @@
 
 menu Security options
 
+config SNS_SIGNED
+   bool Enable sns-signed binaries (EXPERIMENTAL)
+   depends on (EXT2_FS_XATTR || EXT3_FS_XATTR || EXT4DEV_FS_XATTR || 
REISERFS_FS_XATTR || JFFS2_FS_XATTR || 

[PATCH] sns: check related executable memory of binaries [3/4]

[Alexander Wuerstlein]

From: Johannes Schlumberger [EMAIL PROTECTED]

Checks on mmap and mprotect (i.e. libraries) wether they are signed and adjusts
the processe's signed flag accordingly.

If a process looses its signed state it gets, in our current design, killed, for
it is no longer trustworthy. A process also looses its signed flag if it 
mprotects
any memory as executable.

Signed-off-by: Johannes Schlumberger [EMAIL PROTECTED]
---
 include/linux/mm.h  |3 ++
 include/linux/sns.h |   17 +++
 kernel/fork.c   |7 
 mm/mmap.c   |   79 +++
 mm/mprotect.c   |   30 +++
 security/Kconfig|   36 +++
 security/sns.c  |   10 ++
 7 files changed, 176 insertions(+), 6 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index e4183c6..903bc45 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -112,6 +112,9 @@ struct vm_area_struct {
 #ifdef CONFIG_NUMA
struct mempolicy *vm_policy;/* NUMA policy for the VMA */
 #endif
+#ifdef CONFIG_SNS_SIGNED
+   int sns_valid_sig;
+#endif
 };
 
 extern struct kmem_cache *vm_area_cachep;
diff --git a/include/linux/sns.h b/include/linux/sns.h
index ad15e4b..eefb6e7 100644
--- a/include/linux/sns.h
+++ b/include/linux/sns.h
@@ -1,3 +1,20 @@
 #ifdef CONFIG_SNS_SIGNED
 int sns_signature_valid(struct file *);
+int sns_signature_becomes_invalid(void);
+
+/*
+ * The following is unfortunately necessary, there does not seem to be a
+ * common define to find out wether some ominous DSO which somebody
+ * likes to mmap or mprotect is in fact trustworthy kernel code.
+ */
+#ifdef CONFIG_X86
+#define sns_is_gate_vdso(addr, len) (addr==0xe000  len == PAGE_SIZE)
+#else
+#ifdef CONFIG_IA64
+#define sns_is_gate_vdso(addr, len) (addr==0xe000UL  len == PAGE_SIZE)
+#else
+#define sns_is_gate_vdso(addr, len) 0
+#endif
+#endif
+
 #endif
diff --git a/kernel/fork.c b/kernel/fork.c
index c12cf61..b1afa57 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -260,6 +260,9 @@ static inline int dup_mmap(struct mm_struct *mm, struct 
mm_struct *oldmm)
file = tmp-vm_file;
if (file) {
struct inode *inode = file-f_path.dentry-d_inode;
+#ifdef CONFIG_SNS_SIGNED
+   tmp-sns_valid_sig = mpnt-sns_valid_sig;
+#endif
get_file(file);
if (tmp-vm_flags  VM_DENYWRITE)
atomic_dec(inode-i_writecount);
@@ -271,6 +274,10 @@ static inline int dup_mmap(struct mm_struct *mm, struct 
mm_struct *oldmm)
vma_prio_tree_add(tmp, mpnt);
flush_dcache_mmap_unlock(file-f_mapping);
spin_unlock(file-f_mapping-i_mmap_lock);
+#ifdef CONFIG_SNS_SIGNED
+   } else {
+   tmp-sns_valid_sig = 0;
+#endif
}
 
/*
diff --git a/mm/mmap.c b/mm/mmap.c
index 68b9ad2..1f4bdf0 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -25,6 +25,9 @@
 #include linux/mount.h
 #include linux/mempolicy.h
 #include linux/rmap.h
+#ifdef CONFIG_SNS_SIGNED
+#include linux/sns.h
+#endif
 
 #include asm/uaccess.h
 #include asm/cacheflush.h
@@ -1101,10 +1104,33 @@ munmap_back:
error = file-f_op-mmap(file, vma);
if (error)
goto unmap_and_free_vma;
-   } else if (vm_flags  VM_SHARED) {
-   error = shmem_zero_setup(vma);
-   if (error)
-   goto free_vma;
+#ifdef CONFIG_SNS_SIGNED
+   if (current-sns_valid_sig  (vm_flags  VM_EXEC)) {
+   if (vm_flags  VM_WRITE){
+   vma-sns_valid_sig = 0;
+   current-sns_valid_sig = 0;
+   sns_signature_becomes_invalid();
+   } else {
+   vma-sns_valid_sig = sns_signature_valid(file);
+   current-sns_valid_sig = vma-sns_valid_sig;
+   if(!current-sns_valid_sig)
+   sns_signature_becomes_invalid();
+   }
+   }
+#endif
+   } else {
+#ifdef CONFIG_SNS_SIGNED
+   /* JIT could have written some evil code here, which we are 
unable to verify */
+   if (prot  PROT_EXEC  current-sns_valid_sig) {
+   if ((vma-sns_valid_sig = (current-sns_valid_sig = 
(sns_is_gate_vdso(addr, len)
+   sns_signature_becomes_invalid();
+   }
+#endif
+   if (vm_flags  VM_SHARED) {
+   error = shmem_zero_setup(vma);
+   if (error)
+   goto free_vma;
+   }
}
 
/* We set VM_ACCOUNT in a shared mapping's vm_flags, to inform
@@ -1946,8 +1972,49 @@ unsigned long 

[PATCH] sns: add syscall to check signed state of a process [4/4]

[Alexander Wuerstlein]

Makes it possible for a userspace process to ask for the trustworthiness of
another process.

Signed-off-by: Johannes Schlumberger [EMAIL PROTECTED]
---
 arch/i386/kernel/syscall_table.S |1 +
 include/asm-i386/unistd.h|3 ++-
 security/sns.c   |   15 +++
 3 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/arch/i386/kernel/syscall_table.S b/arch/i386/kernel/syscall_table.S
index bf6adce..e8ba35a 100644
--- a/arch/i386/kernel/syscall_table.S
+++ b/arch/i386/kernel/syscall_table.S
@@ -323,3 +323,4 @@ ENTRY(sys_call_table)
.long sys_signalfd
.long sys_timerfd
.long sys_eventfd
+   .long sys_sns_is_trusted/* 320 */
diff --git a/include/asm-i386/unistd.h b/include/asm-i386/unistd.h
index e84ace1..3f8df3e 100644
--- a/include/asm-i386/unistd.h
+++ b/include/asm-i386/unistd.h
@@ -329,10 +329,11 @@
 #define __NR_signalfd  321
 #define __NR_timerfd   322
 #define __NR_eventfd   323
+#define __NR_sns_is_trusted324
 
 #ifdef __KERNEL__
 
-#define NR_syscalls 324
+#define NR_syscalls 325
 
 #define __ARCH_WANT_IPC_PARSE_VERSION
 #define __ARCH_WANT_OLD_READDIR
diff --git a/security/sns.c b/security/sns.c
index 3192a90..1978f7c 100644
--- a/security/sns.c
+++ b/security/sns.c
@@ -112,3 +112,18 @@ int sns_signature_valid(struct file *file)
crypto_free_hash(tfm);
return ret;
 }
+
+asmlinkage int sys_sns_is_trusted(pid_t p)
+{
+   struct task_struct *t;
+   rcu_read_lock();
+   t = find_task_by_pid(p);
+   if (IS_ERR(t)) {
+   rcu_read_unlock();
+   return -EINVAL;
+   }
+   p = t-sns_valid_sig; /*locking needed*/
+   rcu_read_unlock();
+   return p;
+}
+EXPORT_SYMBOL_GPL(sys_sns_is_trusted);
-- 
1.5.2.1

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

Re: [PATCH] Check files' signatures before doing suid/sgid [2/4]

[Alexander Wuerstlein]

On 070621 19:33, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-06-21 at 19:25 +0200, Alexander Wuerstlein wrote:
> > On 070621 19:21, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > > On Thu, 2007-06-21 at 18:02 +0200, Alexander Wuerstlein wrote:
> > > > Modified task_struct to hold a 'signed flag' which is set on exec(), 
> > > > inherited
> > > > on fork() and checked during exec before giving the new process 
> > > > suid/sgid
> > > > privileges.
> > > > 
> > > 
> > > 
> > > 
> > > do you also check the signature of glibc and every other shared library
> > > that the app uses (or dlopens)? if not.. the entire exercise is rather
> > > pointless...
> > 
> > We do check that, that is patch [3/4].
> > 
> > Of course we can only check mmap-ed files, if there is no file like with JIT
> > compilers we are out of luck.
> 
> or if the process uses read() not mmap().

If a process uses read() it needs some executable and writable memory. We do
check for this in mprotect(). There is a problem with the i386-architecture,
because it allows execution of any readable page (except with newer
processors). But beyond that ugliness of i386, it should not be possible to
execute anything without us noticing it (hopefully).

Scripting languages are of course problematic. In the suid-case you could just
call anyone insane who wants to use a suid-shellscript. But in other cases one
might want signed binaries for, we do have a problem. With java or shell one
would need an interpreter/vm which is signed and reasonably trustworthy itself
and checks the signature of the shellscript or classfile it executes.  The
(probably not all too complicated) writing of such an interpreter is left as an
exercise to the reader ;)



Ciao,

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

Re: [PATCH] signed binaries support [0/4]

[Alexander Wuerstlein]

On 070621 19:26, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 21, 2007 at 06:29:17PM +0200, Alexander Wuerstlein wrote:
> > On 070621 18:19, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > > On Thu, Jun 21, 2007 at 05:55:16PM +0200, Johannes Schlumberger wrote:
> > > 
> > > > Hi,
> > > 
> > > Hi Johannes,
> > > 
> > > > We (two students of CS) built a system for signing binaries and 
> > > > verifying them
> > > > before executing. Our main focus was to implement a way to inhibit 
> > > > execution
> > > > of suid-binaries, which are not trustworthy (i.e. not signed).
> > > >...
> > > 
> > > doesn't anyone who is able to install a not trustworthy suid-binary 
> > > already have the priviliges to do anything he wants to without requiring 
> > > an suid bit?
> > 
> > Yes, quite correct in most cases. But if you have taken control of a 
> > computer
> > on of the more common ways to keep the control for some time is the
> > installation of a suid-binary (e.g. as part of a rootkit). 
> 
> There are so many ways for manipulating a computer that controlling 
> setuid binaries hardly brings a real security gain.

Even if it does not really improve security too much it can be helpful as a
part of a larger system. For example around here we use a 'sbit-checker' that
basically does a 'find' and 'chmod', which we would be able to replace by this
patch.

Also our patch is not solely about suid-binaries, we just implemented
suid-checking because it seemed a simple and obvious thing to do.  Our real aim
was to implement binary signatures, which can be used in numerous security
related checks around the kernel. Btw. if you have any good ideas where one
could use them, please tell us :)



Ciao,

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

Re: [PATCH] Check files' signatures before doing suid/sgid [2/4]

[Alexander Wuerstlein]

On 070621 19:21, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-06-21 at 18:02 +0200, Alexander Wuerstlein wrote:
> > Modified task_struct to hold a 'signed flag' which is set on exec(), 
> > inherited
> > on fork() and checked during exec before giving the new process suid/sgid
> > privileges.
> > 
> 
> 
> 
> do you also check the signature of glibc and every other shared library
> that the app uses (or dlopens)? if not.. the entire exercise is rather
> pointless...

We do check that, that is patch [3/4].

Of course we can only check mmap-ed files, if there is no file like with JIT
compilers we are out of luck.


Ciao,

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

Re: [PATCH] sns: add syscall to check signed state of a process [4/4]

[Alexander Wuerstlein]

On 070621 18:34, Akinobu Mita <[EMAIL PROTECTED]> wrote:
> 2007/6/22, Alexander Wuerstlein <[EMAIL PROTECTED]>:
>
>> +asmlinkage int sys_sns_is_trusted(pid_t p)
>> +{
>> +   struct task_struct *t;
>> +   rcu_read_lock();
>> +   t = find_task_by_pid(p);
>> +   if (IS_ERR(t)) {
>
> Shouldn't it be:
> if (!t) {
>...
> ?
>
> find_task_by_pid() returns NULL on failure.

You seem to be right, the rest of the kernel just does 'if (!t)'. We just used
IS_ERR() as the 'check for evil pointers' function.




Ciao,

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

Re: [PATCH] signed binaries support [0/4]

[Alexander Wuerstlein]

On 070621 18:19, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 21, 2007 at 05:55:16PM +0200, Johannes Schlumberger wrote:
> 
> > Hi,
> 
> Hi Johannes,
> 
> > We (two students of CS) built a system for signing binaries and verifying 
> > them
> > before executing. Our main focus was to implement a way to inhibit execution
> > of suid-binaries, which are not trustworthy (i.e. not signed).
> >...
> 
> doesn't anyone who is able to install a not trustworthy suid-binary 
> already have the priviliges to do anything he wants to without requiring 
> an suid bit?

Yes, quite correct in most cases. But if you have taken control of a computer
on of the more common ways to keep the control for some time is the
installation of a suid-binary (e.g. as part of a rootkit). 

One could also imagine a scenario where an attacker controls some filesystems
(on external storage perhaps) where he can of course manipulate the suid bit,
but he does not have direct control over the attacked system unless he can
execute that file.



Ciao,

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

[PATCH] Check files' signatures before doing suid/sgid [2/4]

[Alexander Wuerstlein]

Modified task_struct to hold a 'signed flag' which is set on exec(), inherited
on fork() and checked during exec before giving the new process suid/sgid
privileges.

sns.c contains our helper functions to verify the signatures.
sns_secret_key.dat contains the 'secret key' which is used for HMAC.

Signed-off-by: Johannes Schlumberger <[EMAIL PROTECTED]>
---
 fs/exec.c   |   19 +++-
 include/linux/Kbuild|2 +
 include/linux/sched.h   |3 +
 include/linux/sns.h |3 +
 kernel/fork.c   |6 +++
 security/Kconfig|   28 
 security/Makefile   |1 +
 security/sns.c  |  104 +++
 security/sns_secret_key.dat |5 ++
 9 files changed, 169 insertions(+), 2 deletions(-)
 create mode 100644 include/linux/sns.h
 create mode 100644 security/sns.c
 create mode 100644 security/sns_secret_key.dat

diff --git a/fs/exec.c b/fs/exec.c
index f20561f..5dfa406 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -51,6 +51,9 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_SNS_SIGNED
+#include 
+#endif
 
 #include 
 #include 
@@ -928,13 +931,21 @@ int prepare_binprm(struct linux_binprm *bprm)
mode = inode->i_mode;
if (bprm->file->f_op == NULL)
return -EACCES;
+#ifdef CONFIG_SNS_SIGNED
+   if (mode & S_ISUID)
+   current->sns_valid_sig = sns_signature_valid(bprm->file);
+#endif
 
bprm->e_uid = current->euid;
bprm->e_gid = current->egid;
 
if(!(bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID)) {
/* Set-uid? */
-   if (mode & S_ISUID) {
+#ifdef CONFIG_SNS_SIGNED_SETUID
+   if (mode & S_ISUID && current->sns_valid_sig) {
+#else
+   if (mode & S_ISUID) {
+#endif /*SNS_SIGNED_SETUID*/
current->personality &= ~PER_CLEAR_ON_SETID;
bprm->e_uid = inode->i_uid;
}
@@ -945,7 +956,11 @@ int prepare_binprm(struct linux_binprm *bprm)
 * is a candidate for mandatory locking, not a setgid
 * executable.
 */
-   if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) {
+#ifdef CONFIG_SNS_SIGNED_SETGID
+   if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP) && 
current->sns_valid_sig) {
+#else
+   if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) {
+#endif /*SNS_SIGNED_SETGID*/
current->personality &= ~PER_CLEAR_ON_SETID;
bprm->e_gid = inode->i_gid;
}
diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index f317c27..16df5f0 100644
--- a/include/linux/Kbuild
+++ b/include/linux/Kbuild
@@ -159,6 +159,7 @@ header-y += videotext.h
 header-y += vt.h
 header-y += wireless.h
 header-y += x25.h
+header-y += sns.h
 
 unifdef-y += acct.h
 unifdef-y += adb.h
@@ -347,5 +348,6 @@ unifdef-y += watchdog.h
 unifdef-y += wireless.h
 unifdef-y += xattr.h
 unifdef-y += xfrm.h
+unifdef-y += sns.h
 
 objhdr-y += version.h
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 693f0e6..36c58d6 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1076,6 +1076,9 @@ struct task_struct {
 #ifdef CONFIG_FAULT_INJECTION
int make_it_fail;
 #endif
+#ifdef CONFIG_SNS_SIGNED
+   int sns_valid_sig;
+#endif
 };
 
 static inline pid_t process_group(struct task_struct *tsk)
diff --git a/include/linux/sns.h b/include/linux/sns.h
new file mode 100644
index 000..ad15e4b
--- /dev/null
+++ b/include/linux/sns.h
@@ -0,0 +1,3 @@
+#ifdef CONFIG_SNS_SIGNED
+int sns_signature_valid(struct file *);
+#endif
diff --git a/kernel/fork.c b/kernel/fork.c
index 73ad5cd..c12cf61 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -156,6 +156,9 @@ void __init fork_init(unsigned long mempages)
init_task.signal->rlim[RLIMIT_NPROC].rlim_max = max_threads/2;
init_task.signal->rlim[RLIMIT_SIGPENDING] =
init_task.signal->rlim[RLIMIT_NPROC];
+#ifdef CONFIG_SNS_SIGNED
+   init_task.sns_valid_sig = 0;
+#endif
 }
 
 static struct task_struct *dup_task_struct(struct task_struct *orig)
@@ -182,6 +185,9 @@ static struct task_struct *dup_task_struct(struct 
task_struct *orig)
 #ifdef CONFIG_CC_STACKPROTECTOR
tsk->stack_canary = get_random_int();
 #endif
+#ifdef CONFIG_SNS_SIGNED
+   tsk->sns_valid_sig = orig->sns_valid_sig;
+#endif
 
/* One for us, one for whoever does the "release_task()" (usually 
parent) */
atomic_set(>usage,2);
diff --git a/security/Kconfig b/security/Kconfig
index 460e5c9..bfaace7 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -4,6 +4,34 @@
 
 menu "Security options"
 
+config SNS_SIGNED
+   bool "Enable sns-signed binaries (EXPERIMENTAL)"
+   depends on (EXT2_FS_XATTR || EXT3_FS_XATTR || EXT4DEV_FS_XATTR || 
REISERFS_FS_XATTR || JFFS2_FS_XATTR || CIFS_XATTR) && (CRYPTO_SHA1 || 
CRYPTO_HMAC || 

[PATCH] sns: check related executable memory of binaries [3/4]

[Alexander Wuerstlein]

From: Johannes Schlumberger <[EMAIL PROTECTED]>

Checks on mmap and mprotect (i.e. libraries) wether they are signed and adjusts
the processe's signed flag accordingly.

If a process looses its signed state it gets, in our current design, killed, for
it is no longer trustworthy. A process also looses its signed flag if it 
mprotects
any memory as executable.

Signed-off-by: Johannes Schlumberger <[EMAIL PROTECTED]>
---
 include/linux/mm.h  |3 ++
 include/linux/sns.h |   17 +++
 kernel/fork.c   |7 
 mm/mmap.c   |   79 +++
 mm/mprotect.c   |   30 +++
 security/Kconfig|   36 +++
 security/sns.c  |   10 ++
 7 files changed, 176 insertions(+), 6 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index e4183c6..903bc45 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -112,6 +112,9 @@ struct vm_area_struct {
 #ifdef CONFIG_NUMA
struct mempolicy *vm_policy;/* NUMA policy for the VMA */
 #endif
+#ifdef CONFIG_SNS_SIGNED
+   int sns_valid_sig;
+#endif
 };
 
 extern struct kmem_cache *vm_area_cachep;
diff --git a/include/linux/sns.h b/include/linux/sns.h
index ad15e4b..eefb6e7 100644
--- a/include/linux/sns.h
+++ b/include/linux/sns.h
@@ -1,3 +1,20 @@
 #ifdef CONFIG_SNS_SIGNED
 int sns_signature_valid(struct file *);
+int sns_signature_becomes_invalid(void);
+
+/*
+ * The following is unfortunately necessary, there does not seem to be a
+ * common define to find out wether some ominous DSO which somebody
+ * likes to mmap or mprotect is in fact trustworthy kernel code.
+ */
+#ifdef CONFIG_X86
+#define sns_is_gate_vdso(addr, len) (addr==0xe000 && len == PAGE_SIZE)
+#else
+#ifdef CONFIG_IA64
+#define sns_is_gate_vdso(addr, len) (addr==0xe000UL && len == PAGE_SIZE)
+#else
+#define sns_is_gate_vdso(addr, len) 0
+#endif
+#endif
+
 #endif
diff --git a/kernel/fork.c b/kernel/fork.c
index c12cf61..b1afa57 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -260,6 +260,9 @@ static inline int dup_mmap(struct mm_struct *mm, struct 
mm_struct *oldmm)
file = tmp->vm_file;
if (file) {
struct inode *inode = file->f_path.dentry->d_inode;
+#ifdef CONFIG_SNS_SIGNED
+   tmp->sns_valid_sig = mpnt->sns_valid_sig;
+#endif
get_file(file);
if (tmp->vm_flags & VM_DENYWRITE)
atomic_dec(>i_writecount);
@@ -271,6 +274,10 @@ static inline int dup_mmap(struct mm_struct *mm, struct 
mm_struct *oldmm)
vma_prio_tree_add(tmp, mpnt);
flush_dcache_mmap_unlock(file->f_mapping);
spin_unlock(>f_mapping->i_mmap_lock);
+#ifdef CONFIG_SNS_SIGNED
+   } else {
+   tmp->sns_valid_sig = 0;
+#endif
}
 
/*
diff --git a/mm/mmap.c b/mm/mmap.c
index 68b9ad2..1f4bdf0 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -25,6 +25,9 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_SNS_SIGNED
+#include 
+#endif
 
 #include 
 #include 
@@ -1101,10 +1104,33 @@ munmap_back:
error = file->f_op->mmap(file, vma);
if (error)
goto unmap_and_free_vma;
-   } else if (vm_flags & VM_SHARED) {
-   error = shmem_zero_setup(vma);
-   if (error)
-   goto free_vma;
+#ifdef CONFIG_SNS_SIGNED
+   if (current->sns_valid_sig && (vm_flags & VM_EXEC)) {
+   if (vm_flags & VM_WRITE){
+   vma->sns_valid_sig = 0;
+   current->sns_valid_sig = 0;
+   sns_signature_becomes_invalid();
+   } else {
+   vma->sns_valid_sig = sns_signature_valid(file);
+   current->sns_valid_sig = vma->sns_valid_sig;
+   if(!current->sns_valid_sig)
+   sns_signature_becomes_invalid();
+   }
+   }
+#endif
+   } else {
+#ifdef CONFIG_SNS_SIGNED
+   /* JIT could have written some evil code here, which we are 
unable to verify */
+   if (prot & PROT_EXEC && current->sns_valid_sig) {
+   if ((vma->sns_valid_sig = (current->sns_valid_sig = 
(sns_is_gate_vdso(addr, len)
+   sns_signature_becomes_invalid();
+   }
+#endif
+   if (vm_flags & VM_SHARED) {
+   error = shmem_zero_setup(vma);
+   if (error)
+   goto free_vma;
+   }
}
 
/* We set VM_ACCOUNT in a shared mapping's vm_flags, to inform
@@ -1946,8 +1972,49 @@ unsigned long do_brk(unsigned long addr, unsigned long 
len)

[PATCH] sns: add syscall to check signed state of a process [4/4]

[Alexander Wuerstlein]

Makes it possible for a userspace process to ask for the trustworthiness of
another process.

Signed-off-by: Johannes Schlumberger <[EMAIL PROTECTED]>
---
 arch/i386/kernel/syscall_table.S |1 +
 include/asm-i386/unistd.h|3 ++-
 security/sns.c   |   15 +++
 3 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/arch/i386/kernel/syscall_table.S b/arch/i386/kernel/syscall_table.S
index bf6adce..e8ba35a 100644
--- a/arch/i386/kernel/syscall_table.S
+++ b/arch/i386/kernel/syscall_table.S
@@ -323,3 +323,4 @@ ENTRY(sys_call_table)
.long sys_signalfd
.long sys_timerfd
.long sys_eventfd
+   .long sys_sns_is_trusted/* 320 */
diff --git a/include/asm-i386/unistd.h b/include/asm-i386/unistd.h
index e84ace1..3f8df3e 100644
--- a/include/asm-i386/unistd.h
+++ b/include/asm-i386/unistd.h
@@ -329,10 +329,11 @@
 #define __NR_signalfd  321
 #define __NR_timerfd   322
 #define __NR_eventfd   323
+#define __NR_sns_is_trusted324
 
 #ifdef __KERNEL__
 
-#define NR_syscalls 324
+#define NR_syscalls 325
 
 #define __ARCH_WANT_IPC_PARSE_VERSION
 #define __ARCH_WANT_OLD_READDIR
diff --git a/security/sns.c b/security/sns.c
index 3192a90..1978f7c 100644
--- a/security/sns.c
+++ b/security/sns.c
@@ -112,3 +112,18 @@ int sns_signature_valid(struct file *file)
crypto_free_hash(tfm);
return ret;
 }
+
+asmlinkage int sys_sns_is_trusted(pid_t p)
+{
+   struct task_struct *t;
+   rcu_read_lock();
+   t = find_task_by_pid(p);
+   if (IS_ERR(t)) {
+   rcu_read_unlock();
+   return -EINVAL;
+   }
+   p = t->sns_valid_sig; /*locking needed*/
+   rcu_read_unlock();
+   return p;
+}
+EXPORT_SYMBOL_GPL(sys_sns_is_trusted);
-- 
1.5.2.1

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

[PATCH] export xattr_resolve_name_sns [1/4]

[Alexander Wuerstlein]

From: Johannes Schlumberger <[EMAIL PROTECTED]>

Makes it possible to get extended attributes for a given inode.  We need this
for cases where we no longer have the corresponding direntry.

Signed-off-by: Johannes Schlumberger <[EMAIL PROTECTED]>
---
 fs/xattr.c|   18 ++
 include/linux/xattr.h |1 +
 2 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/fs/xattr.c b/fs/xattr.c
index 4523aca..467417f 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -538,6 +538,24 @@ xattr_resolve_name(struct xattr_handler **handlers, const 
char **name)
return handler;
 }
 
+struct xattr_handler *
+xattr_resolve_name_sns(struct xattr_handler **handlers, const char **name)
+{
+   struct xattr_handler *handler;
+
+   if (!*name)
+   return NULL;
+
+   for_each_xattr_handler(handlers, handler) {
+   const char *n = strcmp_prefix(*name, handler->prefix);
+   if (n) {
+   *name = n;
+   break;
+   }
+   }
+   return handler;
+}
+
 /*
  * Find the handler for the prefix and dispatch its get() operation.
  */
diff --git a/include/linux/xattr.h b/include/linux/xattr.h
index def131a..5653508 100644
--- a/include/linux/xattr.h
+++ b/include/linux/xattr.h
@@ -46,6 +46,7 @@ struct xattr_handler {
   size_t size, int flags);
 };
 
+struct xattr_handler * xattr_resolve_name_sns(struct xattr_handler **, const 
char **);
 ssize_t vfs_getxattr(struct dentry *, char *, void *, size_t);
 ssize_t vfs_listxattr(struct dentry *d, char *list, size_t size);
 int vfs_setxattr(struct dentry *, char *, void *, size_t, int);
-- 
1.5.2.1

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

[PATCH] export xattr_resolve_name_sns [1/4]

[Alexander Wuerstlein]

From: Johannes Schlumberger [EMAIL PROTECTED]

Makes it possible to get extended attributes for a given inode.  We need this
for cases where we no longer have the corresponding direntry.

Signed-off-by: Johannes Schlumberger [EMAIL PROTECTED]
---
 fs/xattr.c|   18 ++
 include/linux/xattr.h |1 +
 2 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/fs/xattr.c b/fs/xattr.c
index 4523aca..467417f 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -538,6 +538,24 @@ xattr_resolve_name(struct xattr_handler **handlers, const 
char **name)
return handler;
 }
 
+struct xattr_handler *
+xattr_resolve_name_sns(struct xattr_handler **handlers, const char **name)
+{
+   struct xattr_handler *handler;
+
+   if (!*name)
+   return NULL;
+
+   for_each_xattr_handler(handlers, handler) {
+   const char *n = strcmp_prefix(*name, handler-prefix);
+   if (n) {
+   *name = n;
+   break;
+   }
+   }
+   return handler;
+}
+
 /*
  * Find the handler for the prefix and dispatch its get() operation.
  */
diff --git a/include/linux/xattr.h b/include/linux/xattr.h
index def131a..5653508 100644
--- a/include/linux/xattr.h
+++ b/include/linux/xattr.h
@@ -46,6 +46,7 @@ struct xattr_handler {
   size_t size, int flags);
 };
 
+struct xattr_handler * xattr_resolve_name_sns(struct xattr_handler **, const 
char **);
 ssize_t vfs_getxattr(struct dentry *, char *, void *, size_t);
 ssize_t vfs_listxattr(struct dentry *d, char *list, size_t size);
 int vfs_setxattr(struct dentry *, char *, void *, size_t, int);
-- 
1.5.2.1

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

[PATCH] sns: add syscall to check signed state of a process [4/4]

[Alexander Wuerstlein]

Makes it possible for a userspace process to ask for the trustworthiness of
another process.

Signed-off-by: Johannes Schlumberger [EMAIL PROTECTED]
---
 arch/i386/kernel/syscall_table.S |1 +
 include/asm-i386/unistd.h|3 ++-
 security/sns.c   |   15 +++
 3 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/arch/i386/kernel/syscall_table.S b/arch/i386/kernel/syscall_table.S
index bf6adce..e8ba35a 100644
--- a/arch/i386/kernel/syscall_table.S
+++ b/arch/i386/kernel/syscall_table.S
@@ -323,3 +323,4 @@ ENTRY(sys_call_table)
.long sys_signalfd
.long sys_timerfd
.long sys_eventfd
+   .long sys_sns_is_trusted/* 320 */
diff --git a/include/asm-i386/unistd.h b/include/asm-i386/unistd.h
index e84ace1..3f8df3e 100644
--- a/include/asm-i386/unistd.h
+++ b/include/asm-i386/unistd.h
@@ -329,10 +329,11 @@
 #define __NR_signalfd  321
 #define __NR_timerfd   322
 #define __NR_eventfd   323
+#define __NR_sns_is_trusted324
 
 #ifdef __KERNEL__
 
-#define NR_syscalls 324
+#define NR_syscalls 325
 
 #define __ARCH_WANT_IPC_PARSE_VERSION
 #define __ARCH_WANT_OLD_READDIR
diff --git a/security/sns.c b/security/sns.c
index 3192a90..1978f7c 100644
--- a/security/sns.c
+++ b/security/sns.c
@@ -112,3 +112,18 @@ int sns_signature_valid(struct file *file)
crypto_free_hash(tfm);
return ret;
 }
+
+asmlinkage int sys_sns_is_trusted(pid_t p)
+{
+   struct task_struct *t;
+   rcu_read_lock();
+   t = find_task_by_pid(p);
+   if (IS_ERR(t)) {
+   rcu_read_unlock();
+   return -EINVAL;
+   }
+   p = t-sns_valid_sig; /*locking needed*/
+   rcu_read_unlock();
+   return p;
+}
+EXPORT_SYMBOL_GPL(sys_sns_is_trusted);
-- 
1.5.2.1

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

[PATCH] Check files' signatures before doing suid/sgid [2/4]

[Alexander Wuerstlein]

Modified task_struct to hold a 'signed flag' which is set on exec(), inherited
on fork() and checked during exec before giving the new process suid/sgid
privileges.

sns.c contains our helper functions to verify the signatures.
sns_secret_key.dat contains the 'secret key' which is used for HMAC.

Signed-off-by: Johannes Schlumberger [EMAIL PROTECTED]
---
 fs/exec.c   |   19 +++-
 include/linux/Kbuild|2 +
 include/linux/sched.h   |3 +
 include/linux/sns.h |3 +
 kernel/fork.c   |6 +++
 security/Kconfig|   28 
 security/Makefile   |1 +
 security/sns.c  |  104 +++
 security/sns_secret_key.dat |5 ++
 9 files changed, 169 insertions(+), 2 deletions(-)
 create mode 100644 include/linux/sns.h
 create mode 100644 security/sns.c
 create mode 100644 security/sns_secret_key.dat

diff --git a/fs/exec.c b/fs/exec.c
index f20561f..5dfa406 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -51,6 +51,9 @@
 #include linux/cn_proc.h
 #include linux/audit.h
 #include linux/signalfd.h
+#ifdef CONFIG_SNS_SIGNED
+#include linux/sns.h
+#endif
 
 #include asm/uaccess.h
 #include asm/mmu_context.h
@@ -928,13 +931,21 @@ int prepare_binprm(struct linux_binprm *bprm)
mode = inode-i_mode;
if (bprm-file-f_op == NULL)
return -EACCES;
+#ifdef CONFIG_SNS_SIGNED
+   if (mode  S_ISUID)
+   current-sns_valid_sig = sns_signature_valid(bprm-file);
+#endif
 
bprm-e_uid = current-euid;
bprm-e_gid = current-egid;
 
if(!(bprm-file-f_path.mnt-mnt_flags  MNT_NOSUID)) {
/* Set-uid? */
-   if (mode  S_ISUID) {
+#ifdef CONFIG_SNS_SIGNED_SETUID
+   if (mode  S_ISUID  current-sns_valid_sig) {
+#else
+   if (mode  S_ISUID) {
+#endif /*SNS_SIGNED_SETUID*/
current-personality = ~PER_CLEAR_ON_SETID;
bprm-e_uid = inode-i_uid;
}
@@ -945,7 +956,11 @@ int prepare_binprm(struct linux_binprm *bprm)
 * is a candidate for mandatory locking, not a setgid
 * executable.
 */
-   if ((mode  (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) {
+#ifdef CONFIG_SNS_SIGNED_SETGID
+   if ((mode  (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)  
current-sns_valid_sig) {
+#else
+   if ((mode  (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) {
+#endif /*SNS_SIGNED_SETGID*/
current-personality = ~PER_CLEAR_ON_SETID;
bprm-e_gid = inode-i_gid;
}
diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index f317c27..16df5f0 100644
--- a/include/linux/Kbuild
+++ b/include/linux/Kbuild
@@ -159,6 +159,7 @@ header-y += videotext.h
 header-y += vt.h
 header-y += wireless.h
 header-y += x25.h
+header-y += sns.h
 
 unifdef-y += acct.h
 unifdef-y += adb.h
@@ -347,5 +348,6 @@ unifdef-y += watchdog.h
 unifdef-y += wireless.h
 unifdef-y += xattr.h
 unifdef-y += xfrm.h
+unifdef-y += sns.h
 
 objhdr-y += version.h
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 693f0e6..36c58d6 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1076,6 +1076,9 @@ struct task_struct {
 #ifdef CONFIG_FAULT_INJECTION
int make_it_fail;
 #endif
+#ifdef CONFIG_SNS_SIGNED
+   int sns_valid_sig;
+#endif
 };
 
 static inline pid_t process_group(struct task_struct *tsk)
diff --git a/include/linux/sns.h b/include/linux/sns.h
new file mode 100644
index 000..ad15e4b
--- /dev/null
+++ b/include/linux/sns.h
@@ -0,0 +1,3 @@
+#ifdef CONFIG_SNS_SIGNED
+int sns_signature_valid(struct file *);
+#endif
diff --git a/kernel/fork.c b/kernel/fork.c
index 73ad5cd..c12cf61 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -156,6 +156,9 @@ void __init fork_init(unsigned long mempages)
init_task.signal-rlim[RLIMIT_NPROC].rlim_max = max_threads/2;
init_task.signal-rlim[RLIMIT_SIGPENDING] =
init_task.signal-rlim[RLIMIT_NPROC];
+#ifdef CONFIG_SNS_SIGNED
+   init_task.sns_valid_sig = 0;
+#endif
 }
 
 static struct task_struct *dup_task_struct(struct task_struct *orig)
@@ -182,6 +185,9 @@ static struct task_struct *dup_task_struct(struct 
task_struct *orig)
 #ifdef CONFIG_CC_STACKPROTECTOR
tsk-stack_canary = get_random_int();
 #endif
+#ifdef CONFIG_SNS_SIGNED
+   tsk-sns_valid_sig = orig-sns_valid_sig;
+#endif
 
/* One for us, one for whoever does the release_task() (usually 
parent) */
atomic_set(tsk-usage,2);
diff --git a/security/Kconfig b/security/Kconfig
index 460e5c9..bfaace7 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -4,6 +4,34 @@
 
 menu Security options
 
+config SNS_SIGNED
+   bool Enable sns-signed binaries (EXPERIMENTAL)
+   depends on (EXT2_FS_XATTR || EXT3_FS_XATTR || EXT4DEV_FS_XATTR || 
REISERFS_FS_XATTR || JFFS2_FS_XATTR || 

[PATCH] sns: check related executable memory of binaries [3/4]

[Alexander Wuerstlein]

From: Johannes Schlumberger [EMAIL PROTECTED]

Checks on mmap and mprotect (i.e. libraries) wether they are signed and adjusts
the processe's signed flag accordingly.

If a process looses its signed state it gets, in our current design, killed, for
it is no longer trustworthy. A process also looses its signed flag if it 
mprotects
any memory as executable.

Signed-off-by: Johannes Schlumberger [EMAIL PROTECTED]
---
 include/linux/mm.h  |3 ++
 include/linux/sns.h |   17 +++
 kernel/fork.c   |7 
 mm/mmap.c   |   79 +++
 mm/mprotect.c   |   30 +++
 security/Kconfig|   36 +++
 security/sns.c  |   10 ++
 7 files changed, 176 insertions(+), 6 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index e4183c6..903bc45 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -112,6 +112,9 @@ struct vm_area_struct {
 #ifdef CONFIG_NUMA
struct mempolicy *vm_policy;/* NUMA policy for the VMA */
 #endif
+#ifdef CONFIG_SNS_SIGNED
+   int sns_valid_sig;
+#endif
 };
 
 extern struct kmem_cache *vm_area_cachep;
diff --git a/include/linux/sns.h b/include/linux/sns.h
index ad15e4b..eefb6e7 100644
--- a/include/linux/sns.h
+++ b/include/linux/sns.h
@@ -1,3 +1,20 @@
 #ifdef CONFIG_SNS_SIGNED
 int sns_signature_valid(struct file *);
+int sns_signature_becomes_invalid(void);
+
+/*
+ * The following is unfortunately necessary, there does not seem to be a
+ * common define to find out wether some ominous DSO which somebody
+ * likes to mmap or mprotect is in fact trustworthy kernel code.
+ */
+#ifdef CONFIG_X86
+#define sns_is_gate_vdso(addr, len) (addr==0xe000  len == PAGE_SIZE)
+#else
+#ifdef CONFIG_IA64
+#define sns_is_gate_vdso(addr, len) (addr==0xe000UL  len == PAGE_SIZE)
+#else
+#define sns_is_gate_vdso(addr, len) 0
+#endif
+#endif
+
 #endif
diff --git a/kernel/fork.c b/kernel/fork.c
index c12cf61..b1afa57 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -260,6 +260,9 @@ static inline int dup_mmap(struct mm_struct *mm, struct 
mm_struct *oldmm)
file = tmp-vm_file;
if (file) {
struct inode *inode = file-f_path.dentry-d_inode;
+#ifdef CONFIG_SNS_SIGNED
+   tmp-sns_valid_sig = mpnt-sns_valid_sig;
+#endif
get_file(file);
if (tmp-vm_flags  VM_DENYWRITE)
atomic_dec(inode-i_writecount);
@@ -271,6 +274,10 @@ static inline int dup_mmap(struct mm_struct *mm, struct 
mm_struct *oldmm)
vma_prio_tree_add(tmp, mpnt);
flush_dcache_mmap_unlock(file-f_mapping);
spin_unlock(file-f_mapping-i_mmap_lock);
+#ifdef CONFIG_SNS_SIGNED
+   } else {
+   tmp-sns_valid_sig = 0;
+#endif
}
 
/*
diff --git a/mm/mmap.c b/mm/mmap.c
index 68b9ad2..1f4bdf0 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -25,6 +25,9 @@
 #include linux/mount.h
 #include linux/mempolicy.h
 #include linux/rmap.h
+#ifdef CONFIG_SNS_SIGNED
+#include linux/sns.h
+#endif
 
 #include asm/uaccess.h
 #include asm/cacheflush.h
@@ -1101,10 +1104,33 @@ munmap_back:
error = file-f_op-mmap(file, vma);
if (error)
goto unmap_and_free_vma;
-   } else if (vm_flags  VM_SHARED) {
-   error = shmem_zero_setup(vma);
-   if (error)
-   goto free_vma;
+#ifdef CONFIG_SNS_SIGNED
+   if (current-sns_valid_sig  (vm_flags  VM_EXEC)) {
+   if (vm_flags  VM_WRITE){
+   vma-sns_valid_sig = 0;
+   current-sns_valid_sig = 0;
+   sns_signature_becomes_invalid();
+   } else {
+   vma-sns_valid_sig = sns_signature_valid(file);
+   current-sns_valid_sig = vma-sns_valid_sig;
+   if(!current-sns_valid_sig)
+   sns_signature_becomes_invalid();
+   }
+   }
+#endif
+   } else {
+#ifdef CONFIG_SNS_SIGNED
+   /* JIT could have written some evil code here, which we are 
unable to verify */
+   if (prot  PROT_EXEC  current-sns_valid_sig) {
+   if ((vma-sns_valid_sig = (current-sns_valid_sig = 
(sns_is_gate_vdso(addr, len)
+   sns_signature_becomes_invalid();
+   }
+#endif
+   if (vm_flags  VM_SHARED) {
+   error = shmem_zero_setup(vma);
+   if (error)
+   goto free_vma;
+   }
}
 
/* We set VM_ACCOUNT in a shared mapping's vm_flags, to inform
@@ -1946,8 +1972,49 @@ unsigned long 

Re: [PATCH] signed binaries support [0/4]

[Alexander Wuerstlein]

On 070621 18:19, Adrian Bunk [EMAIL PROTECTED] wrote:
 On Thu, Jun 21, 2007 at 05:55:16PM +0200, Johannes Schlumberger wrote:
 
  Hi,
 
 Hi Johannes,
 
  We (two students of CS) built a system for signing binaries and verifying 
  them
  before executing. Our main focus was to implement a way to inhibit execution
  of suid-binaries, which are not trustworthy (i.e. not signed).
 ...
 
 doesn't anyone who is able to install a not trustworthy suid-binary 
 already have the priviliges to do anything he wants to without requiring 
 an suid bit?

Yes, quite correct in most cases. But if you have taken control of a computer
on of the more common ways to keep the control for some time is the
installation of a suid-binary (e.g. as part of a rootkit). 

One could also imagine a scenario where an attacker controls some filesystems
(on external storage perhaps) where he can of course manipulate the suid bit,
but he does not have direct control over the attacked system unless he can
execute that file.



Ciao,

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

Re: [PATCH] sns: add syscall to check signed state of a process [4/4]

[Alexander Wuerstlein]

On 070621 18:34, Akinobu Mita [EMAIL PROTECTED] wrote:
 2007/6/22, Alexander Wuerstlein [EMAIL PROTECTED]:

 +asmlinkage int sys_sns_is_trusted(pid_t p)
 +{
 +   struct task_struct *t;
 +   rcu_read_lock();
 +   t = find_task_by_pid(p);
 +   if (IS_ERR(t)) {

 Shouldn't it be:
 if (!t) {
...
 ?

 find_task_by_pid() returns NULL on failure.

You seem to be right, the rest of the kernel just does 'if (!t)'. We just used
IS_ERR() as the 'check for evil pointers' function.




Ciao,

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

Re: [PATCH] Check files' signatures before doing suid/sgid [2/4]

[Alexander Wuerstlein]

On 070621 19:21, Arjan van de Ven [EMAIL PROTECTED] wrote:
 On Thu, 2007-06-21 at 18:02 +0200, Alexander Wuerstlein wrote:
  Modified task_struct to hold a 'signed flag' which is set on exec(), 
  inherited
  on fork() and checked during exec before giving the new process suid/sgid
  privileges.
  
 
 
 
 do you also check the signature of glibc and every other shared library
 that the app uses (or dlopens)? if not.. the entire exercise is rather
 pointless...

We do check that, that is patch [3/4].

Of course we can only check mmap-ed files, if there is no file like with JIT
compilers we are out of luck.


Ciao,

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

Re: [PATCH] signed binaries support [0/4]

[Alexander Wuerstlein]

On 070621 19:26, Adrian Bunk [EMAIL PROTECTED] wrote:
 On Thu, Jun 21, 2007 at 06:29:17PM +0200, Alexander Wuerstlein wrote:
  On 070621 18:19, Adrian Bunk [EMAIL PROTECTED] wrote:
   On Thu, Jun 21, 2007 at 05:55:16PM +0200, Johannes Schlumberger wrote:
   
Hi,
   
   Hi Johannes,
   
We (two students of CS) built a system for signing binaries and 
verifying them
before executing. Our main focus was to implement a way to inhibit 
execution
of suid-binaries, which are not trustworthy (i.e. not signed).
   ...
   
   doesn't anyone who is able to install a not trustworthy suid-binary 
   already have the priviliges to do anything he wants to without requiring 
   an suid bit?
  
  Yes, quite correct in most cases. But if you have taken control of a 
  computer
  on of the more common ways to keep the control for some time is the
  installation of a suid-binary (e.g. as part of a rootkit). 
 
 There are so many ways for manipulating a computer that controlling 
 setuid binaries hardly brings a real security gain.

Even if it does not really improve security too much it can be helpful as a
part of a larger system. For example around here we use a 'sbit-checker' that
basically does a 'find' and 'chmod', which we would be able to replace by this
patch.

Also our patch is not solely about suid-binaries, we just implemented
suid-checking because it seemed a simple and obvious thing to do.  Our real aim
was to implement binary signatures, which can be used in numerous security
related checks around the kernel. Btw. if you have any good ideas where one
could use them, please tell us :)



Ciao,

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

Re: [PATCH] Check files' signatures before doing suid/sgid [2/4]

[Alexander Wuerstlein]

On 070621 19:33, Arjan van de Ven [EMAIL PROTECTED] wrote:
 On Thu, 2007-06-21 at 19:25 +0200, Alexander Wuerstlein wrote:
  On 070621 19:21, Arjan van de Ven [EMAIL PROTECTED] wrote:
   On Thu, 2007-06-21 at 18:02 +0200, Alexander Wuerstlein wrote:
Modified task_struct to hold a 'signed flag' which is set on exec(), 
inherited
on fork() and checked during exec before giving the new process 
suid/sgid
privileges.

   
   
   
   do you also check the signature of glibc and every other shared library
   that the app uses (or dlopens)? if not.. the entire exercise is rather
   pointless...
  
  We do check that, that is patch [3/4].
  
  Of course we can only check mmap-ed files, if there is no file like with JIT
  compilers we are out of luck.
 
 or if the process uses read() not mmap().

If a process uses read() it needs some executable and writable memory. We do
check for this in mprotect(). There is a problem with the i386-architecture,
because it allows execution of any readable page (except with newer
processors). But beyond that ugliness of i386, it should not be possible to
execute anything without us noticing it (hopefully).

Scripting languages are of course problematic. In the suid-case you could just
call anyone insane who wants to use a suid-shellscript. But in other cases one
might want signed binaries for, we do have a problem. With java or shell one
would need an interpreter/vm which is signed and reasonably trustworthy itself
and checks the signature of the shellscript or classfile it executes.  The
(probably not all too complicated) writing of such an interpreter is left as an
exercise to the reader ;)



Ciao,

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