[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-security-module
Subject:    Re: [RFC][PATCH] Pass requested protection to
From:       Stephen Smalley <sds () epoch ! ncsc ! mil>
Date:       2005-02-23 13:09:58
Message-ID: 1109164198.17298.17.camel () moss-spartans ! epoch ! ncsc ! mil
[Download RAW message or body]

On Tue, 2005-02-22 at 15:47 -0800, Chris Wright wrote:
> Only other way I can see is to effectively tweak policy based on
> tsk->personality.  While it seems ugly, it's an accurate reflection
> of both policy and reality (with some confusion of audit messages when
> building policy).  But your patch is probably the most straight-forward
> way to do it.

Yes, the patch lets us distinguish between application-requested execute
protection and the implied execute protection by read-implies-exec
logic, which I think is useful, e.g. we'll still apply execute-related
checking when ld.so explicitly requests an executable mapping.  It also
avoids having to explicitly check current->personality and file-
>f_vfsmnt->mnt_flags again for READ_IMPLIES_EXEC and MNT_NOEXEC
respectively in the security module.

> Do you want to sample prot after it's been cleared of GROWSUP/DOWN bits
> just to keep reqport as clean as possible?

Good idea.

> unnecessary initialization

Ok, thanks.

> Looks an unnecessary duplicate 

Yes, good catch.

Ok, I'll rework accordingly and plan to submit post 2.6.11.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

[prev in list] [next in list] [prev in thread] [next in thread]