What the hell are you laughing at?

24 January 2010 21:50

Slaughter

I received my first patch to slaughter today, which made me happy.

(I've made a new release including it, and updated the list of primitives to actually document the file-deletion facilities which previously I'd omitted to avoid encouraging mass-breakage.)

Signing Binaries

Andrew Pollock mentions that the days of elfsign might be numbered.

This is a shame because I've always liked the idea of signing binaries. Once upon a time, in the 2.4.x days, I wrote a kernel patch which would refuse to execute non-signed binaries. (This was mostly a waste of time; since it denied the execution of shell scripts. Which meant that the system init scripts mostly failed. My solution in the end was to only modprobe my module once the system was up and running, and hope for the best ...)

Right now, having performed only a quick search, I don't see anything like that at the moment.

elfsign will let you store a binaries MD5 hash.

bsign will let you sign a binary with a GPG key.

But where is the kernel patch to only execute such hashed/signed binaries, preventing the execution of random shell scripts and potentially trojaned binaries?

Without that I think signing binaries is a crazyish thing to do. Sure you can test that a file hasn't been modified, but even without those tools you can do the same thing via md5sums.

(ObRandom: Clearly if you mass-modify all your binaries the system md5sums database will be trashed.)

Perl UTF

I've received a bug report against chronicle, my blog compiler.

It seems that some versions of perl fail to run this:
     #
     #  Run the command, reading stdout.
     #
    open( FILTER, "$cmd|;utf8" ) or
       die "Failed to run filter: $!";
Removing the ;utf8 filter allows things to work, but will trash any UTF-8 characters from the output - so that's a nasty solution.

I'm not sure what the sane solution is here, so I'm going to sit on it for a few days and continue to write test scripts.

ObSubject: 300

Tags: bsign, chronicle, md5sum, slaughter | 6 comments

Comments on this entry

Jon at 11:32 on 25 January 2010

There's been a lot of UTF-8 fixes in ikiwiki recently, especially ones relating to odd or old perl versions. It might be worth your while looking at the recent bug fixes there to pre-empt further reports against chronicle.

Jim at 21:16 on 24 January 2010

Just as a thought experiment, let's see if we can implement "signed binaries" without involving the kernel.

First, define the goals -- root can do anything on a system, including change the kernel, so presumably you're trying to prevent non-root users from running untrusted binaries.

But there's no reason to put policy in the kernel! The kernel already provides a mechanism to make the distinction between "these binaries can be executed" and "these binaries cannot be executed" -- in the "exec" and "noexec" mount options.

You can mount two filesystems. One is the normal filesystem that users can write to, but it's mounted "noexec". The other is writable only by root, and is mounted "exec".

"Verifying" a binary or script on the "noexec" filesystem then means that the root user copies the binary to the "exec" filesystem, and makes a symbolic link to it from the appropriate place in the "noexec" filesystem.

"Verifying" could also be performed by a setuid program that performs whatever cryptographic signature checks you desire, if you're looking to automate things.

Steve at 19:05 on 24 January 2010

Storing signatures as attributes would be enough to make me happy, as it would give you the protection without causing your (existing) binary checksums to break.

Still I think it is mostly academic unless the kernel enforces validation on any signatures - wherever they might be stored.

Steve Kemp at 19:04 on 24 January 2010

I'll try the binmode approach, thanks for the suggestion.

FWIW I agree with you about the open format. That's the only one in my codebase - the rest of the opens are of the form:

    open my $handle, "&lt;:utf8", $filename or
       die "Blah ..";

I'll make the perlcritic warnings fatal in the future to ensure I don't add any more in.

Ray Lee at 18:42 on 24 January 2010

Wouldn't it make more sense to store the signature as an extended attribute?

Tomaž at 16:34 on 24 January 2010
http://www.tablix.org/~avian/blog

Did you try opening FILTER without ";utf8" and then doing binmode(FILTER, ":utf8")?

Two-argument variant of open() is evil anyway - I think it's good practice to always give the mode string and command/filename in separate arguments.

What the hell are you laughing at?

Comments on this entry

Recent Posts