From: stefan.bavendiek@mailbox.org
To: kernel-hardening@lists.openwall.com
Cc: linux-hardening@vger.kernel.org
Subject: Kernel complexity
Date: Sat, 12 Dec 2020 21:08:52 +0100 [thread overview]
Message-ID: <X9UjVOuTgwuQwfFk@mailbox.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 2167 bytes --]
Hi,
first of all, thanks to everyone here for this awesome project and the work you do.
Personally I am interested in Linux Kernel Security and especially features supporting attack surface reduction. In the past I did some work on sandboxing features like seccomp support in user space applications. I have been rather hesitant to get involved here, since I am not a full time developer and certainly not an expert in C programming.
However I am currently doing a research project that aims to identify risk areas in the kernel by measuring code complexity metrics and assuming this might help this project, I would like to ask for some feedback in case this work can actually help with this project.
My approach is basically to take a look at the different system calls and measure the complexity of the code involved in their execution. Since code complexity has already been found to have a strong correlation with the probability of existing vulnerabilities, this might indicate kernel areas that need a closer look.
Additionally the functionality of the syscall will also be considered for a final risk score, although most of the work for this part has already been done in [1].
The objective is to create a risk score matrix for linux syscalls that consists of the functionality risk according to [1], times the measured complexity.
This will (hopefully) be helpful to identify risk areas in the kernel and provide user space developers with an measurement that can help design secure software and sandboxing features.
One major aspect I am still not sure about is the challenges regarding the dynamic measure of code path execution. While it is possible to measure the cyclomatic complexity of the kernel code with existing tools, I am not sure how much value the results would have, given that this does not include the dynamic code path behind each syscall. I was thinking of using ftrace to follow and measure the execution path. Any feedback and advise on this for this would be appreciated.
-- Stefan
Ref.
[1] Massimo Bernaschi, Emanuele Gabrielli, and Luigi Mancini. Remus: A security-enhanced Operating system (2002)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next reply other threads:[~2020-12-12 21:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-12 20:08 stefan.bavendiek [this message]
2020-12-12 22:34 ` Kernel complexity Jann Horn
2020-12-13 19:04 ` stefan.bavendiek
2020-12-14 6:34 ` Greg KH
2020-12-15 6:09 ` Sandy Harris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=X9UjVOuTgwuQwfFk@mailbox.org \
--to=stefan.bavendiek@mailbox.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-hardening@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).