Hi all,
DSI development team would like to announce the release 1.3.1 of digsig.
This kernel module helps system administrators control Executable and
Linkable Format (ELF) binary execution and library loading based on
the presence of a valid digital signature. The main functionality is
to help system administrators distinguish applications he/she trusts
(and therefore signs) from viruses, worms (and other nuisances). It is
based on the Linux Security Module hooks.
The code is GPL and available from:
http://sourceforge.net/projects/disec/, download digsig-1.3.1. For
more documentation, please refer to disec.sourcefrge.net.
I hope that it'll be useful to you.
All bug reports and feature requests or general feedback are welcome
(please CC me or [email protected] in your answer or
feedback to the mailing list).
Regards,
Makan Pourzandi
Changes from Digsig release 0.2 announced in this mailing list:
================================================================
- the verification of signatures for the shared binaries has been
added.
- added support for caching of signatures
- added documentation for digsig
- added support for revoked signatures
- support to avoid vulnerability for rewrite of shared
libraries
- use sysfs to connect to the module instead of the char device
- code clean up, and some bug fixes
Future works
=============
- improving the caching and revocation: it is currently tested
and will be sent out soon after stability testing
overview
=======
Instead of writing a long detailed explication, I rather give you an
example of how you can use it.
A Very simple scenario to show how to use it
=======================================
1) Generate gpg key and export your public key in order to use it for
signature verification.
$gpg --gen-key
=> careful generate RSA key
$gpg --export >> my_public_key.pub
2) Sign your binaries using Bsign
Before using bsign to sign all your binaries, try out with a simple
example.
$cp `which ps` ps-test
$bsign -s ps-test // sign the binary
$bsign -v ps-test // be sure that the signature is valid
3) Make the digsig module
From ./digsig, do make -C /usr/src/linux-2.5.66 SUBDIRS=$PWD modules.
You need rw access to /usr/src/linux-2.5.66.
CAREFUL: we advice you to compile the module in debug mode at your
first tries (see -DDSI_DEBUG -DDSI_DIGSIG_DEBUG in the Makefile). In
this mode, the module verifies the signatures but does not enforce the
security (if not any signature present in your binary, you'll have a
message in /var/log/messages but the execution is not
aborted.). However, the execution of the binaries with invalid
signatures is aborted. Once, you're sure of your binary signature
procedure you can recompile the whole on non-debug mode.
4) load digsig, use the public key exported in step 1 as argument
root@colby digsig-dev]# ./digsig.init start pubkey.pub
Loading Digsig module.
Making device for communication with the module.
Loading public key.
Done.
root@colby digsig-dev]#
5) In debug mode:
$./ps-test
$tail -f /var/log/messages
Sep 16 15:49:16 colby kernel: DSI-LSM MODULE - binary is ./ps-test
Sep 16 15:49:16 colby kernel: DSI-LSM MODULE - dsi_bprm_compute_creds:
Found signature section
Sep 16 15:49:16 colby kernel: DSI-LSM MODULE - dsi_bprm_compute_creds:
Signature verification successful
$ps
// no check for not signed binaries
$tail -f /var/log/messages
Sep 16 15:49:16 colby kernel: DSI-LSM MODULE - binary is ./ps
6) In restrictive mode, normal mode
You need to use bsign to sign all binaries that you want to run in
normal mode.
// signed binary
[lmcmpou@reblochon lmcmpou]$ ps
PID TTY TIME CMD
6897 pts/2 00:00:00 bash
6941 pts/2 00:00:00 ps
// not signed binary
[lmcmpou@reblochon lmcmpou]$ ./ps-makan-1
bash: ./ps-makan: cannot execute binary file
// binary with wrong signature
[lmcmpou@reblochon lmcmpou]$ ./ps-makan-2
bash: ./ps-makan-colby: Operation not permitted
7) Unload the module.
[root@colby digsig-dev]# ./digsig.init stop
Unloading Digsig.
Performances
===============
Finally, to provide a better insight into the actual impact of DigSig
on real workloads, three kernel compiles were timed on a non-DigSig
system, and three on a digsig system. The tests were performed using
a 2.6.7 kernel on a Pentium 4 2.4GHz with 512 MB of RAM. The kernel
being compiled was a 2.6.4 kernel, and the same .config was used for
each compile. Each compile was preceded by a ``make clean''. The
first execution both with and without DigSig appears to reflect extra
time needed to load the kernel source data files from disk.
The results are presented below:
------------------------
Kernel without DigSig |
------------------------|
real | sys |
19m21.890s | 1m27.992s |
19m9.276s | 1m26.584s |
19m9.464s | 1m26.191s |
19m7.717s | 1m25.799s |
------------------------
Kernel with DigSig
------------------------
real | sys |
19m19.957s | 1m28.541s |
19m7.485s | 1m26.832s |
19m7.883s | 1m26.549s |
19m6.494s | 1m26.618s |
------------------------
Requirements:
==============
Linux OS kernel 2.5.66 or higher. We tested against 2.5.66 and
2.6.0-test5.
Bsign version
0.4.5. (http://packages.debian.org/unstable/admin/bsign.html)
GPG 1.2.2 or higher.
Merits
=====
This work has been done by (alphabetical order)
A Apvrille ([email protected]),
D Gordon ([email protected]),
S Hallyn ([email protected])
M Pourzandi ([email protected]),
V Roy ([email protected]).
Special Thanks to Greg Kroah-Hartman for his feedback and to Marc Singer
who helped us with the use of Bsign.
Regards,
Makan Pourzandi
-------------------------------------------------------
Makan Pourzandi, Open Systems Lab
Ericsson Research Canada [email protected]
This email does not represent or express the opinions of
Ericsson Inc.
-------------------------------------------------------
* Makan Pourzandi ([email protected]) wrote:
> Hi all,
>
> DSI development team would like to announce the release 1.3.1 of digsig.
>
> This kernel module helps system administrators control Executable and
> Linkable Format (ELF) binary execution and library loading based on
> the presence of a valid digital signature. The main functionality is
> to help system administrators distinguish applications he/she trusts
> (and therefore signs) from viruses, worms (and other nuisances). It is
> based on the Linux Security Module hooks.
>
> The code is GPL and available from:
> http://sourceforge.net/projects/disec/, download digsig-1.3.1. For
> more documentation, please refer to disec.sourcefrge.net.
>
> I hope that it'll be useful to you.
>
> All bug reports and feature requests or general feedback are welcome
> (please CC me or [email protected] in your answer or
> feedback to the mailing list).
>
> Regards,
> Makan Pourzandi
>
> Changes from Digsig release 0.2 announced in this mailing list:
> ================================================================
>
> - the verification of signatures for the shared binaries has been
> added.
> - added support for caching of signatures
> - added documentation for digsig
> - added support for revoked signatures
> - support to avoid vulnerability for rewrite of shared
> libraries
Could you elaborate on this one?
> - use sysfs to connect to the module instead of the char device
> - code clean up, and some bug fixes
>
> Future works
> =============
>
> - improving the caching and revocation: it is currently tested
> and will be sent out soon after stability testing
Should be helpful enough to cache result until thing's opened for
writing, or is that what you're doing now?
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
> > - support to avoid vulnerability for rewrite of shared
> > libraries
>
> Could you elaborate on this one?
When a file is being executed, deny_write_access(file) is called to
prevent writing until execution completes. Because deny_write_access
is not exported from fs/namei.c, we emulate this behavior for shared
libraries.
> > Future works
> > =============
> >
> > - improving the caching and revocation: it is currently tested
> > and will be sent out soon after stability testing
>
> Should be helpful enough to cache result until thing's opened for
> writing, or is that what you're doing now?
Exactly. When the file is opened for writing (which as much as possible
requires the file to not be executed), we uncache the signature
validation.
(The new patch hashes revocations (they were on a linked list), and
steals the seqlock-based structure Rik van Riel had suggested for
the selinux avc cache for use in the signature revocation cache. There
is no change in functionality, only (hopefully) performance improvements.)
-serge
* Serge E. Hallyn ([email protected]) wrote:
> > > - support to avoid vulnerability for rewrite of shared
> > > libraries
> >
> > Could you elaborate on this one?
>
> When a file is being executed, deny_write_access(file) is called to
> prevent writing until execution completes. Because deny_write_access
> is not exported from fs/namei.c, we emulate this behavior for shared
> libraries.
Hmm, ok, so you're relying on the loader to do PROT_EXEC mmaps for
shared libraries? Probably not required at least on x86. Also, does
this work when executing loader directly (/lib/ld.so /bin/ps), and with
dlopen?
> > > Future works
> > > =============
> > >
> > > - improving the caching and revocation: it is currently tested
> > > and will be sent out soon after stability testing
> >
> > Should be helpful enough to cache result until thing's opened for
> > writing, or is that what you're doing now?
>
> Exactly. When the file is opened for writing (which as much as possible
> requires the file to not be executed), we uncache the signature
> validation.
>
> (The new patch hashes revocations (they were on a linked list), and
> steals the seqlock-based structure Rik van Riel had suggested for
> the selinux avc cache for use in the signature revocation cache. There
> is no change in functionality, only (hopefully) performance improvements.)
Ok, I see. Makes sense.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Hi Chris,
Chris Wright wrote:
> * Makan Pourzandi ([email protected]) wrote:
>>
>>DSI development team would like to announce the release 1.3.1 of digsig.
...
>>
>>Changes from Digsig release 0.2 announced in this mailing list:
>>================================================================
>>
>> - the verification of signatures for the shared binaries has been
>> added.
>> - added support for caching of signatures
>> - added documentation for digsig
>> - added support for revoked signatures
>> - support to avoid vulnerability for rewrite of shared
>> libraries
>
>
> Could you elaborate on this one?
We realized that when a shared library is opened by a binary it can
still be modified. To solve the problem, we block the write access to
the shared binary while it is loaded.
>
>
>> - use sysfs to connect to the module instead of the char device
>> - code clean up, and some bug fixes
>>
>>Future works
>>=============
>>
>> - improving the caching and revocation: it is currently tested
>> and will be sent out soon after stability testing
>
>
> Should be helpful enough to cache result until thing's opened for
> writing, or is that what you're doing now?
>
This is what we're doing now, but we need to implement a hash table to
accelerate the lookup for the signatures.
Regards,
Makan
> thanks,
> -chris
--
Makan Pourzandi, Open Systems Lab
Ericsson Research, Montreal, Canada
*This email does not represent or express the opinions of Ericsson Inc.*
* Makan Pourzandi ([email protected]) wrote:
> Hi Chris,
>
> Chris Wright wrote:
> > * Makan Pourzandi ([email protected]) wrote:
> >>
> >>DSI development team would like to announce the release 1.3.1 of digsig.
> ...
> >>
> >>Changes from Digsig release 0.2 announced in this mailing list:
> >>================================================================
> >>
> >> - the verification of signatures for the shared binaries has been
> >> added.
> >> - added support for caching of signatures
> >> - added documentation for digsig
> >> - added support for revoked signatures
> >> - support to avoid vulnerability for rewrite of shared
> >> libraries
> >
> >
> > Could you elaborate on this one?
>
> We realized that when a shared library is opened by a binary it can
> still be modified. To solve the problem, we block the write access to
> the shared binary while it is loaded.
AFAICT, this means anybody with read access to a file can block all
writes. This doesn't sound great.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
> > When a file is being executed, deny_write_access(file) is called to
> > prevent writing until execution completes. Because deny_write_access
> > is not exported from fs/namei.c, we emulate this behavior for shared
> > libraries.
>
> Hmm, ok, so you're relying on the loader to do PROT_EXEC mmaps for
> shared libraries? Probably not required at least on x86.
Correct.
We don't pretend to stop someone from mmap'ing and executing bad code, we
only want to help someone who wants to use a legitimate library to know that
the right library is being used.
> Also, does
> this work when executing loader directly (/lib/ld.so /bin/ps), and with
> dlopen?
Yup, both of these (at least on i386) use mmap with PROT_EXEC, and go
through digsig's dsi_file_mmap check. (I've made a note to check the
/lib/ld.so /bin/ps case on a powerpc and, if I can find one, z)
-serge
Quoting Chris Wright ([email protected]):
> * Makan Pourzandi ([email protected]) wrote:
...
> > We realized that when a shared library is opened by a binary it can
> > still be modified. To solve the problem, we block the write access to
> > the shared binary while it is loaded.
>
> AFAICT, this means anybody with read access to a file can block all
> writes. This doesn't sound great.
True.
This could be fixed by adding a check at the top of dsi_file_mmap for
file->f_dentry->d_inode->i_mode & MAY_EXEC. Of course then shared
libraries which are installed without execute permissions will cause
apps to break. On my quick test, I couldn't run xterm or vi :)
Note that blocking writes requires that the file be a valid ELF file,
as this is all that digsig mediates. So I'm not sure which we worry
about more - the fact that all shared libraries have to be installed
with execute permissions (under the proposed solution), or that write
to an ELF file can be prevented by mmap(PROT_EXEC). Presumably, if
you are replacing an ELF file, you will always want to do
"mv foo.so foo.so.del; cp new/foo.so foo.so" anyway.
Thoughts?
thanks,
-serge
Serge E. Hallyn wrote:
> Quoting Chris Wright ([email protected]):
>
>>* Makan Pourzandi ([email protected]) wrote:
>
> ...
>
>>>We realized that when a shared library is opened by a binary it can
>>>still be modified. To solve the problem, we block the write access to
>>>the shared binary while it is loaded.
>>
>>AFAICT, this means anybody with read access to a file can block all
>>writes. This doesn't sound great.
>
>
> True.
>
I want to narrow down the discussion, I believe that some people could
get confused with the mention of "file" here. AFAICT, the above problem
only concerns the shared libraries. Digsig applies only to binaries: in
digsig_file_mmap() implementing the file_mmap LSM hook, if the file is
not executable there is a return and no verification or any other
blocking is done.
For executables, there is no meaning to load them on read mode, you
should have execute permission. if you then load them for execution
IMHO, it makes sense to block the writing on that file.
For shared libraries, you're right. the problem exists, the shared
libraries can be loaded being only readable (even though I remember
reading in exec.c:sys_uselib() kernel 2.6.8.1 that the shared libraries
must be both readable and executable due to "security reasons", but I'm
not an expert and definitely readable is enough to load the shared
library but I'll be happy to learn more about this.)
> This could be fixed by adding a check at the top of dsi_file_mmap for
> file->f_dentry->d_inode->i_mode & MAY_EXEC. Of course then shared
> libraries which are installed without execute permissions will cause
> apps to break. On my quick test, I couldn't run xterm or vi :)
>
> Note that blocking writes requires that the file be a valid ELF file,
> as this is all that digsig mediates. So I'm not sure which we worry
> about more - the fact that all shared libraries have to be installed
> with execute permissions (under the proposed solution), or that write
My 2 cents, a quick browsing on my machine (fedora core 1) shows that
almost all my shared libraries are installed with both execution and
read permissions. IMHO, I don't believe then that this should be
considered as a major issue.
> to an ELF file can be prevented by mmap(PROT_EXEC). Presumably, if
Regards,
Makan
> you are replacing an ELF file, you will always want to do
> "mv foo.so foo.so.del; cp new/foo.so foo.so" anyway.
>
> Thoughts?
>
> thanks,
> -serge
>
--
Makan Pourzandi, Open Systems Lab
Ericsson Research, Montreal, Canada
*This email does not represent or express the opinions of Ericsson Inc.*
* Makan Pourzandi ([email protected]) wrote:
> Serge E. Hallyn wrote:
> > Quoting Chris Wright ([email protected]):
> >>AFAICT, this means anybody with read access to a file can block all
> >>writes. This doesn't sound great.
> >
> > True.
>
> I want to narrow down the discussion, I believe that some people could
> get confused with the mention of "file" here. AFAICT, the above problem
> only concerns the shared libraries. Digsig applies only to binaries: in
> digsig_file_mmap() implementing the file_mmap LSM hook, if the file is
> not executable there is a return and no verification or any other
> blocking is done.
No, it's the mmap PROT check that's the issue.
> For executables, there is no meaning to load them on read mode, you
> should have execute permission. if you then load them for execution
> IMHO, it makes sense to block the writing on that file.
Thing is, x86 makes no distinction btween r/x so, have you tried mmaping
with read, then executing (I haven't)? If it works, then you may find
that there are dumb things out there that do that as well (which you
wouldn't be able to protect, and become one attack vector). You can make
a file read-only (no exec bits), and still execute it with ld.so. Same
as bash can interpret readonly shell script files. Now, ld.so _will_
mmap PROT_EXEC, so it works for you.
> For shared libraries, you're right. the problem exists, the shared
> libraries can be loaded being only readable (even though I remember
> reading in exec.c:sys_uselib() kernel 2.6.8.1 that the shared libraries
> must be both readable and executable due to "security reasons", but I'm
> not an expert and definitely readable is enough to load the shared
> library but I'll be happy to learn more about this.)
>
> > This could be fixed by adding a check at the top of dsi_file_mmap for
> > file->f_dentry->d_inode->i_mode & MAY_EXEC. Of course then shared
> > libraries which are installed without execute permissions will cause
> > apps to break. On my quick test, I couldn't run xterm or vi :)
> >
> > Note that blocking writes requires that the file be a valid ELF file,
> > as this is all that digsig mediates. So I'm not sure which we worry
> > about more - the fact that all shared libraries have to be installed
> > with execute permissions (under the proposed solution), or that write
>
>
> My 2 cents, a quick browsing on my machine (fedora core 1) shows that
> almost all my shared libraries are installed with both execution and
> read permissions. IMHO, I don't believe then that this should be
> considered as a major issue.
This has nothing to do with file permissions aside of read. All you need
is read permission, then you can mmap(PROT_EXEC) which will kick off the
check, and do deny_write_access. It's a freeform way to lock writers
out of any readable file in the system. This is why MAP_EXECUTABLE and
MAP_DENYWRITE are masked off at syscall entry.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
> Thing is, x86 makes no distinction btween r/x so, have you tried mmaping
> with read, then executing (I haven't)?
Yup, clearly that will work on x86. And so obviously DigSig is not
a solution to format and buffer overflows :) Nor, unfortunately, a
solution to code which for whatever reason exploited this behavior.
> This has nothing to do with file permissions aside of read. All you need
> is read permission, then you can mmap(PROT_EXEC) which will kick off the
> check, and do deny_write_access. It's a freeform way to lock writers
> out of any readable file in the system.
No, not "any readable file," because DigSig will not lock non-ELF files.
The attached patch adds a check for execute permission to the file being
mmap'ed. Failing such permission, it will return -EPERM and not lock
the file.
thanks,
-serge
Hi all,
see below:
Chris Wright wrote:
> * Makan Pourzandi ([email protected]) wrote:
>
>>Serge E. Hallyn wrote:
>>
>>>Quoting Chris Wright ([email protected]):
>>>
>>>>AFAICT, this means anybody with read access to a file can block all
>>>>writes. This doesn't sound great.
>>>
>>>True.
>>
>>>This could be fixed by adding a check at the top of dsi_file_mmap for
>>>file->f_dentry->d_inode->i_mode & MAY_EXEC. Of course then shared
>>>libraries which are installed without execute permissions will cause
>>>apps to break. On my quick test, I couldn't run xterm or vi :)
>>>
>>>Note that blocking writes requires that the file be a valid ELF file,
>>>as this is all that digsig mediates. So I'm not sure which we worry
>>>about more - the fact that all shared libraries have to be installed
>>>with execute permissions (under the proposed solution), or that write
>>
>>
>>My 2 cents, a quick browsing on my machine (fedora core 1) shows that
>>almost all my shared libraries are installed with both execution and
>>read permissions. IMHO, I don't believe then that this should be
>>considered as a major issue.
>
>
> This has nothing to do with file permissions aside of read. All you need
> is read permission, then you can mmap(PROT_EXEC) which will kick off the
> check, and do deny_write_access. It's a freeform way to lock writers
> out of any readable file in the system. This is why MAP_EXECUTABLE and
> MAP_DENYWRITE are masked off at syscall entry.
Chris, my understanding is that Serge's patch even though it restricts a
little the system admin, is the best solution we have for time being. Am
I right?
If this is the case I'll include Serge's patch in the cvs source code
and send out a new release soon.
regards,
Makan
>
> thanks,
> -chris
--
Makan Pourzandi, Open Systems Lab
Ericsson Research, Montreal, Canada
*This email does not represent or express the opinions of Ericsson Inc.*
* Serge E. Hallyn ([email protected]) wrote:
> > Thing is, x86 makes no distinction btween r/x so, have you tried mmaping
> > with read, then executing (I haven't)?
>
> Yup, clearly that will work on x86. And so obviously DigSig is not
> a solution to format and buffer overflows :) Nor, unfortunately, a
heh
> solution to code which for whatever reason exploited this behavior.
That's what I was getting at. Beats me what's out there that does this,
but I expect some stuff does, and it wouldn't get the same assurance.
> > This has nothing to do with file permissions aside of read. All you need
> > is read permission, then you can mmap(PROT_EXEC) which will kick off the
> > check, and do deny_write_access. It's a freeform way to lock writers
> > out of any readable file in the system.
>
> No, not "any readable file," because DigSig will not lock non-ELF files.
Ahh, this is the part I had missed.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
* Makan Pourzandi ([email protected]) wrote:
> Hi all,
>
> see below:
>
> Chris Wright wrote:
> > * Makan Pourzandi ([email protected]) wrote:
> >
> >>Serge E. Hallyn wrote:
> >>
> >>>Quoting Chris Wright ([email protected]):
> >>>
> >>>>AFAICT, this means anybody with read access to a file can block all
> >>>>writes. This doesn't sound great.
> >>>
> >>>True.
> >>
> >>>This could be fixed by adding a check at the top of dsi_file_mmap for
> >>>file->f_dentry->d_inode->i_mode & MAY_EXEC. Of course then shared
> >>>libraries which are installed without execute permissions will cause
> >>>apps to break. On my quick test, I couldn't run xterm or vi :)
> >>>
> >>>Note that blocking writes requires that the file be a valid ELF file,
> >>>as this is all that digsig mediates. So I'm not sure which we worry
> >>>about more - the fact that all shared libraries have to be installed
> >>>with execute permissions (under the proposed solution), or that write
> >>
> >>
> >>My 2 cents, a quick browsing on my machine (fedora core 1) shows that
> >>almost all my shared libraries are installed with both execution and
> >>read permissions. IMHO, I don't believe then that this should be
> >>considered as a major issue.
> >
> >
> > This has nothing to do with file permissions aside of read. All you need
> > is read permission, then you can mmap(PROT_EXEC) which will kick off the
> > check, and do deny_write_access. It's a freeform way to lock writers
> > out of any readable file in the system. This is why MAP_EXECUTABLE and
> > MAP_DENYWRITE are masked off at syscall entry.
>
> Chris, my understanding is that Serge's patch even though it restricts a
> little the system admin, is the best solution we have for time being. Am
> I right?
> If this is the case I'll include Serge's patch in the cvs source code
> and send out a new release soon.
The key piece I had missed is that it only checks elf files (I now see
read_elf_header). So, the test may even be superfluous. But try it,
see what breaks, then send fixes upstream ;-) BTW, the read_elf_header
returns NULL on error, but IS_ERR is used against the returned pointer
(so errors will oops). Also, the security_set_operations +
set_digsig_ops looks like it should be replaced with static structure
member assignment. The digsig_sem can be statically setup with
DECLARE_MUTEX(). digsig.c::secondary should be static.
digsig.c::digsig_num_cached_sigs should be static and declared in
digsig_cache.c. I'll keep digging.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net