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
tripwire database?

> # 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
only. :-)

Take care,

Bill