[cgl_discussion] Re: Latest version of security requirements document

[Greg KH]

On Thu, Oct 24, 2002 at 06:32:31PM -0400, Makan Pourzandi (LMC) wrote:
> >	- Personally I would not recommend the LIDS project to run on
> >	  any CGL type machine.  If you take a look at the code, you
> >	  will see why.
> 
> I believe this is a very valid comment. For time being, we only try to
> enumerate different projects. Later, we'll choose the valid candidates. 

What critera are you going to use to determine "valid candidates"?

> >	- Stating that MAC is a "requirement" is pretty strong.  I like
> >	  it :)
> 
> I consider splitting requirement into 2: one requirement regarding LSM and
> one requirement regarding MAC module. Any comment on this? 

Sounds good to me.

> Am I right to believe that you want to have digital signature in kernel
> space for all binaries as a must? I don't believe that we wrote that the
> digital signatures must be verified at kernel level for all binaries.

No, I thought that was what you were stating.  But it is a good idea :)

> Actually, there are different possible solutions with different degrees of
> security. For example, one easy solution is that digital signatures can be
> verified as a cron task for all binaries (i.e. when the server's load is low
> and at user level, background task), and alarms sent if any invalid
> signature detected. This can be implemented using tripwire for example.
> Notice that we are talking carrier-grade server, we do not talking about
> wild downloads from web and binaries installed or updated every day.
> Generally, the binaries on these servers change slowly compared to many
> other servers. As a first step, it seems to me that this solution is
> accpetable. 

You _hope_ the binaries do not change.  That's what tools like what was
mentioned are there to catch.  If someone replaces your version of sshd
with a trojaned one, you want to catch that _right away_ before you run
it.  So having the kernel check on every exec() is necessary for things
like that, otherwise you are always playing catch up, and not doing
anything preventative.

> On the other hand, one step further can be to verify the signatures only
> when we load a binary from hard disk for the first time and not verifying
> the signatures when forking.

Yes, this is reasonable.

> Once more, my understanding from a carrier-grade server is that the
> server does not run a wide range of binaries but rather a limited
> number of binaries, this is a dedicated machine to run only one or few
> applications. 

It only takes one application :)

> c.f. my comments above. If we use a step wise approach, we can implement an
> easy solution using the existing open source projects for the first
> releases. Later on, we can complete that solution. what do you think about
> this approach? 

Some security is better than none, as long as you realize the
limitations of the security tools you are implementing.  So tripwire is
great for somethings (auditing mostly), but not good for others
(preventing modified binaries from running.)

> >	- and finally, are people going to be willing to accept the
> >	  speed slow down this feature would cause to their OS?  I know
> >	  the document mentions "doing this in the background", do you
> >	  have any design documents on how this would be successfully
> >	  done without ever running a invalidly signed program?
> >
> I believe you have a very important issue here. There is a price to pay for
> security. 

There always is, security is never free.  You don't have to convince me
of this...

thanks,

greg k-h