Date: Thu, 7 Sep 2006 02:26:53 +0100 From: 473219@googlemail.com To: "Christian S.J. Peron" <csjp@freebsd.org> Cc: trustedbsd-discuss@freebsd.org Subject: Re: Kernel module to deny execution of unsigned binaries? Message-ID: <e782d7390609061826m552ca7x7a8bb1de6e60592e@mail.gmail.com> In-Reply-To: <44F64812.9030107@FreeBSD.org> References: <e782d7390608301128s53c02cedhb73f12a590d2798d@mail.gmail.com> <200608302101.46323.max@love2party.net> <44F64812.9030107@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 31/08/06, Christian S.J. Peron <csjp@freebsd.org> wrote: > Here are the highlights worth noting for mac_chkexec: > > mac_chkexec prevents the execution of (1) binaries, (2) shared objects > and (3) kernel modules which have been modified (back doored with > trojans et al). Each binary has a cryptographic checksum associated with > it, stored as an extended attribute to the file itself. > > How it works is when the binary is executed, or when a shared object is > mmap()'ed into the address space of the process, the kernel calculates > the checksum of the data, and compares it against the checksum > referenced by the inode, if the checksums don't match, the policy > rejects access. Christian, Thanks for the info. It sounds quite powerful. Does this system allow the checksum to be a digital signature instead? A potential customer has asked that no file be executed unless signed with their master key, to prove that the executable was issued by their central office. The kernel would check that the executable file had a digital signature signed by the central office - so even if you gained full write access to the directory, you would be unable to execute your malicious program unless you had compromised the signer's private key. Thanks again!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e782d7390609061826m552ca7x7a8bb1de6e60592e>