Re: Port of secure fd handling to LSM

gregat_private

On Tue, Aug 07, 2001 at 11:48:34AM -0700, Casey Schaufler wrote:
> David Wagner wrote:
> > 
> > richard offer  wrote:
> > >But the argument was that fds are not useful for any policy.
> > 
> > No, I think you're mis-stating the argument.
> 
> Richard has addressed the arguement which was presented.

The argument was:
	Only audit needed the fd passed to all of those different hooks.
	For all other security projects, the struct file was more than
	sufficient.

Someone brought up the point that possibly the OpenWall like protection
of the low fd numbers might need the fd passed in the hook, and Richard
has proven that no, it is not needed.  Thanks Richard!  Give that man a
raise!

> We have one, and I realize that it's taboo to reintroduce
> audit (audit bad, smell funny) but it's a very real policy
> component. I'm sorry that y'all have decided that by itself
> it's not enough of an arguement. We're trying to demonstrate
> that audit is not the only scheme which might use fds,
> and having done so we now get "oh, that's not what I meant".
> 
> Golly Hoppers! What more to do?

Prove that some _real_ project besides audit needs to know the fd.  Not
a "made up" one.  But something that exists today, that does not entail
auditing.

> How about a policy which requires all STDIN be logged? Or
> is that too much like audit? How about a policy which requires
> STDIN to be the physical console device for processes with
> uid=0? That's actually very reasonable in a server
> environment, and you need both the inode (to get the device number)
> and the fd (to check for stdin) to enforce that.

Hm, I remember such a looney project existing for Linux in the past.
Does anyone remember the name of it?

Remember, you can determine from the struct file if the file being
accessed is stdin :)

In fact, I still think you can get anything you want from the struct
file (dup(2) isn't a good argument, simply scan the file pointers for
_all_ matching instances, not just the first one, if you want to do such
a check.)

> And if we can't do what we need to do, we don't win, we lose.
> I understand that you don't win if fds get passed, but I don't
> understand how it is you lose if they do. This has been our
> concern (gripe, if you will) all along, that there is no
> substantive reason to deny our needs, only a claim that we
> don't need them.

Ah, no one is denying that audit needs this.  Just that we aren't doing
audit right now.  Your persistence is inspiring :)

thanks,

greg k-h

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