[cap-talk] New here

[Mike Samuel]

2009/4/27 Juanjo Conti <jjconti at gmail.com>:
> Hi, I am new here. Here meaning: this list, cap sys world, language security
> world.
>
> I am trying to do some research at my university[*] and "Secure Code" or
> "How to code secure programs" is one of the available subjects.
>
> I've spent some days reading about this, I founded E, read about cap sys vs
> ACL systems, also read about aproach to make existing programming languejes
> more secure (for example, about CapPython)
>
> After reading all this, I still have doubts, maybe more that before start
> reading :)
>
> I hope you can provide me some guide.
>
> First of all, what do you consider a secure programming language?

A language which makes it easy for skilled programmers to write
programs with useful&verifiable security properties.


> Does this kind of programming language prevent from security holes?
> Accidental and intentional ones?

It is very hard to prevent accidental problems.  Security holes that
arise from convincing naive users to grant too much authority often
can't be solved technology, but well designed programs allow users to
recover once they realize they've made a mistake, and some programming
languages with support for snapshotting of state or revocation of
authority can make writing such programs easier.


> If a secure programming language (like E) is writing using a non secure
> programming language (like Java), don't we have a problem?

As Raoul pointed out, there's always some foundational layer over
which you have little control, so you have to trust something.

But it's better to trust something that has been proven reliable.  But
if you want to build a new system, then you have to write new code
which can't have been proven to be anything.  So you can either try to
solve the problem of proving properties of your program, which is
hard, or you can try to write as little code as possible about which
you have to prove anything.

The goal of secure languages is to allow building of systems that have
a small TCB (Trusted Computing Base) -- the bits of the system that
are required to work for the system to have useful security properties
should be small.

This separation into TCB and non-TCB is useful in practice when the
TCB is something whose properties are well understood.  You can be
fairly confident that a stable version of the linux kernel preserves
process separation because it has been widely reviewed is used by a
lot of people in security critical environments, so it is probably
safer to have the linux kernel in your TCB, than an arbitrary OS class
student's kernel.

Even if you can't get all of your program outside the TCB, secure
programming languages often let you separate your own program into TCB
and non-TCB portions -- a kernel program within a larger program -- so
that you can focus your analysis and testing on a small critical
portion.


> Thanks in advance!
>
> [*] Universidad Tecnológica Nacional, Argentina
> --
> Juanjo Conti
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>
>