Re: GACI item list - to give some items for discussion

Previous message: Chris Wright: "Re: intercepting system calls"
Next in thread: Shane Kerr: "Re: GACI item list - to give some items for discussion"
Reply: Shane Kerr: "Re: GACI item list - to give some items for discussion"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

dawat_private

richard offer wrote:
>Because I'm trying to write a well behaved application that doesn't generate
>more errors than it needs too ?

What do you mean?  The canonical code is something like
  if ((fd = open(path, O_RDONLY)) < 0) {
    return NULL; /* open failed */
  }
  /* use fd */
This is the usual Unix way.  You seem to be arguing that apps need to
be able to write code like this:
  if (allowed_to_open(path, O_RDONLY) < 0) {
    return NULL; /* open failed */
  }
  fd = open(path, O_RDONLY);
  /* use fd */
I'd argue that the latter is, if anything, *worse* than the former.
It's more error-prone: What if the open() really fails?  It's also
more dangerous: What about race conditions and TOCTTOU attacks?

>I want to give the adminster of the machine useful failure information, not cry
>wolf on every event ?

Then the problem is with your intrusion detection system, not with
the interface to the open() call...

My argument is: We should try for flexibility.  We should of
course allow a module to support this functionality if it wants,
but the question is: Do we require all modules to allow apps to
make allowed_to_open() type of queries?  I don't see any reason
to place this restriction on modules.

If your modules can support allowed_to_open(), and my modules
can deliberately skip implementing it, can we both go home happy?
Or are you suggesting that supporting allowed_to_open() should be
mandatory for all modules?

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module