Re: [PATCH] Check files' signatures before doing suid/sgid [2/4]
Hi,
> >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).
>
> r and x together is not a problem IMHO.
It is, if you would want to have rw but can only get rwx.
regards,
Johannes
--
Johannes Schlumberger Department of Computer Science IV
Martensstrasse 1 D-91058 Erlangen Germany University of Erlangen-Nuremberg
http://wwwcip.informatik.uni-erlangen.de/~spjsschl
-
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]
Hi, 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). r and x together is not a problem IMHO. It is, if you would want to have rw but can only get rwx. regards, Johannes -- Johannes Schlumberger Department of Computer Science IV Martensstrasse 1 D-91058 Erlangen Germany University of Erlangen-Nuremberg http://wwwcip.informatik.uni-erlangen.de/~spjsschl - 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]
Hi, > > 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). > > welcome to mprotect() where the app can just change the permissions We have mprotect covered. If a process tries to mprotect() some pages executable, he had writable before, it is no longer trusted in our current implementation. We are beginning to feel like poeple do not look at our patches, because we screwed up the msg-id, so our Patches are not visible as one clean thread. Sorry for that. regards, Johannes -- Johannes Schlumberger Department of Computer Science IV Martensstrasse 1 D-91058 Erlangen Germany University of Erlangen-Nuremberg http://wwwcip.informatik.uni-erlangen.de/~spjsschl - 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]
Hi, > > 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. > > Something that sounds as if it would increase security but doesn't > really increase security is actually bad since it gives users a false > impression of security. We are aware of the limitations, this approach has. It is not designed to make every bit of executed code trusted, because that what just be the same as before. Everything would be given the same amount of trust. What we do, is establish a caste of binaries and processes more trusted than the rest, which could be used for special tasks. > > 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 :) > Does writing an ELF loader in perl circumvent everything you want to do? No, it does not. We do check any executable pages. regards, Johannes -- Johannes Schlumberger Department of Computer Science IV Martensstrasse 1 D-91058 Erlangen Germany University of Erlangen-Nuremberg http://wwwcip.informatik.uni-erlangen.de/~spjsschl - 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] signed binaries support [0/4]
Hi, 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). Of course this can also be used to grant other access rights, capabilities, etc. The signature (e.g. HMAC-SHA1 with a shared secret) is stored in extended filesystem attributes (userland-signing-tool provided) [1]. Depending on the outcome of our check (performed during exec) a newly introduced flag in the task_struct is set. To be able to also check libraries, we introduced a similar flag in the vm_area struct. Depending on the state of the flag, the suid/sgid bit on the file is honored or ignored. If a process behaves badly (e.g mapping executable memory writable or loading an untrusted library) it is handled appropriately (killed in our current implementation). In the current state our code is of course very expermimental and should be handled with care. We mainly seek comments, suggestions and wisdom before we tackle the more difficult tasks, like proper signatures (public-key-systems, etc.). regards, Johannes [1] http://git.informatik.uni-erlangen.de/?p=ssuid-userland=snapshot;h=HEAD -- Johannes Schlumberger Department of Computer Science IV Martensstrasse 1 D-91058 Erlangen Germany University of Erlangen-Nuremberg http://wwwcip.informatik.uni-erlangen.de/~spjsschl - 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] signed binaries support [0/4]
Hi, 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). Of course this can also be used to grant other access rights, capabilities, etc. The signature (e.g. HMAC-SHA1 with a shared secret) is stored in extended filesystem attributes (userland-signing-tool provided) [1]. Depending on the outcome of our check (performed during exec) a newly introduced flag in the task_struct is set. To be able to also check libraries, we introduced a similar flag in the vm_area struct. Depending on the state of the flag, the suid/sgid bit on the file is honored or ignored. If a process behaves badly (e.g mapping executable memory writable or loading an untrusted library) it is handled appropriately (killed in our current implementation). In the current state our code is of course very expermimental and should be handled with care. We mainly seek comments, suggestions and wisdom before we tackle the more difficult tasks, like proper signatures (public-key-systems, etc.). regards, Johannes [1] http://git.informatik.uni-erlangen.de/?p=ssuid-userlanda=snapshot;h=HEAD -- Johannes Schlumberger Department of Computer Science IV Martensstrasse 1 D-91058 Erlangen Germany University of Erlangen-Nuremberg http://wwwcip.informatik.uni-erlangen.de/~spjsschl - 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]
Hi, 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. Something that sounds as if it would increase security but doesn't really increase security is actually bad since it gives users a false impression of security. We are aware of the limitations, this approach has. It is not designed to make every bit of executed code trusted, because that what just be the same as before. Everything would be given the same amount of trust. What we do, is establish a caste of binaries and processes more trusted than the rest, which could be used for special tasks. 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 :) Does writing an ELF loader in perl circumvent everything you want to do? No, it does not. We do check any executable pages. regards, Johannes -- Johannes Schlumberger Department of Computer Science IV Martensstrasse 1 D-91058 Erlangen Germany University of Erlangen-Nuremberg http://wwwcip.informatik.uni-erlangen.de/~spjsschl - 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]
Hi, 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). welcome to mprotect() where the app can just change the permissions We have mprotect covered. If a process tries to mprotect() some pages executable, he had writable before, it is no longer trusted in our current implementation. We are beginning to feel like poeple do not look at our patches, because we screwed up the msg-id, so our Patches are not visible as one clean thread. Sorry for that. regards, Johannes -- Johannes Schlumberger Department of Computer Science IV Martensstrasse 1 D-91058 Erlangen Germany University of Erlangen-Nuremberg http://wwwcip.informatik.uni-erlangen.de/~spjsschl - 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/
