Subject: Re: Volunteers to test some kernel code...
To: Gandhi woulda smacked you <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 06/22/1999 12:13:24
On Mon, 21 Jun 1999, Gandhi woulda smacked you wrote:
> On Tue, 22 Jun 1999, Brett Lymn wrote:
> # I have been thinking about it too in the light of the comments I have
> # received. I am not totally convinced the idea is a turkey yet but
> # there are some issues which I think do have a bearing:
> # * A working ETXTBSY would mean that running binaries could not be
> # overwritten.
> A bit tangential:
> A working ETXTBSY would be REALLY NICE to have for not only binaries,
> but I'd like to see it available for scripts as well.
For scripts, all we have to do is have exec_script.c set VTEXT too.
> I've always wanted a parameter to a system call to force ETXTBSY on
> a file in that manner...
Maybe add an fcntl that makes an fd assert VTEXT on the underlying vnode.
Though I'm unsure when you'd clear VTEXT in that case. :-)
> Back on topic, this sort of thing looks as if it could qualify for
> C2 inasmuch as it attempts to establish a trusted computing base.
> The difficult part about achieving C2 under *X is that there is no
> set of keystrokes that only the kernel sees which cannot be mapped
> by a userspace program. Of course, I'm sure people will be quick
> to point out that if we want NT, we know to whom to sell our soul...
That's a seperate question. :-)
> # I strongly believe that trying to lock down a system with immutable
> # flags is going to be much harder to reliably achieve. Doing a
> # chflags(1) on all the executables is just the start, you would also
> # need to make a lot more files immutable - even down to the
> # .cshrc/.profile/.login files to ensure things like PATH have not been
> # modified. With my scheme if PATH was manipulated to try and run a
> # trojan it simply would not run. This is what I mean by validating the
> # TCB (Trusted Computing Base). Sure, tripwire can do the same thing
> # but with some riders:
On the dot file stuff, wouldn't you add the important dot files to the
> # 1) Securing the tripwire database is more problematic because the file
> # is referenced by userland code - you can make the file immutable which
> # will address this but you still need to be very careful that the file
> # you think you are access is actually the file you are accessing. With
> # my scheme if you put the signature file under the mount point then it
> # would be very difficult to manipulate the file without unmounting the
> # filesystem.
> # 2) With tripwire there is always a tradeoff between the frequency of
> # running it against the load on the machine. You cannot run tripwire
> # too frequently without loading up the machine. With my scheme the
> # signature is evaluated automatically on exec - there is no need to
> # check binaries that are not run, the result is cached in the kernel so
> # further execs do not re-evaluate the signature. Being in the kernel
> # we can invalidate the cached signature if the file is modified or
> # shifted. Tripwire must evaluate the signatures on each run.
> What kind of signatures are you intent on storing, and is this where
> you'd keep the filehandle information?
> Would there be any benefit to using one of the remaining fields in an
> inode for signature information?
There would be the disadvantage of making the security be fs specific. :-)
And we'd be making our disks binarily incompatable with other OS's. :-(
Plus, where is the file for "/" kept. :-)
> # There is also the issue of stopping people running binaries.
> Ah. You don't want them to be able to run their own programs?
> This seems a bit ... er, Draconian, don't you think?
> [reading ahead to the firewall bit, I understand it a bit better.]
Yes & no. It'd be nice to be able to select which mount points get locked
down. Some servers will want it for everything, some for specific mounts