On 10/26/2013 6:51 AM, Tetsuo Handa wrote:
> Tetsuo Handa wrote:
>> I would send another one which uses only security_file_alloc/free .
> I sent it to James, Casey and Kees on "Fri, 18 Oct 2013 22:56:19 +0900" and
> waiting for your response. How long are we expected to remain vulnerable due
> to
Tetsuo Handa wrote:
> I would send another one which uses only security_file_alloc/free .
I sent it to James, Casey and Kees on "Fri, 18 Oct 2013 22:56:19 +0900" and
waiting for your response. How long are we expected to remain vulnerable due to
lack of multiple concurrent LSM support?
--
To unsub
Hi Kees,
On Thu, Oct 3, 2013 at 6:36 PM, Kees Cook wrote:
> On Fri, Oct 04, 2013 at 06:31:42AM +0900, Tetsuo Handa wrote:
>> Kees Cook wrote:
>> > +static int modpin_load_module(struct file *file)
>> > +{
>> > + struct dentry *module_root;
>> > +
>> > + if (!file) {
>> > + if (!modp
On 10/22/2013 5:02 PM, James Morris wrote:
> On Thu, 17 Oct 2013, Casey Schaufler wrote:
>
>> On 10/17/2013 1:02 AM, James Morris wrote:
>>> This seems like a regression in terms of separating mechanism and policy.
>>>
>>> We have several access control systems available (SELinux, at least) which
On Thu, 17 Oct 2013, Casey Schaufler wrote:
> On 10/17/2013 1:02 AM, James Morris wrote:
> > This seems like a regression in terms of separating mechanism and policy.
> >
> > We have several access control systems available (SELinux, at least) which
> > can implement this functionality with exi
On 10/16/2013 3:43 PM, Kees Cook wrote:
> On Wed, Oct 16, 2013 at 2:42 PM, Casey Schaufler
> wrote:
>> On 10/16/2013 1:47 PM, Tetsuo Handa wrote:
>>> Kees Cook wrote:
Any update on this? It'd be nice to have it in linux-next.
>>> What was the conclusion at LSS about multiple concurrent LSM s
On Thu, Oct 17, 2013 at 10:26 AM, Casey Schaufler
wrote:
> On 10/17/2013 1:02 AM, James Morris wrote:
>> This seems like a regression in terms of separating mechanism and policy.
>>
>> We have several access control systems available (SELinux, at least) which
>> can implement this functionality wi
On Thu, Oct 17, 2013 at 4:30 AM, Jarkko Sakkinen
wrote:
> On Thu, Oct 17, 2013 at 07:02:17PM +1100, James Morris wrote:
>> This seems like a regression in terms of separating mechanism and policy.
>>
>> We have several access control systems available (SELinux, at least) which
>> can implement thi
On 10/17/2013 1:02 AM, James Morris wrote:
> This seems like a regression in terms of separating mechanism and policy.
>
> We have several access control systems available (SELinux, at least) which
> can implement this functionality with existing mechanisms using dynamic
> policy.
They said th
On Thu, Oct 17, 2013 at 07:02:17PM +1100, James Morris wrote:
> This seems like a regression in terms of separating mechanism and policy.
>
> We have several access control systems available (SELinux, at least) which
> can implement this functionality with existing mechanisms using dynamic
> p
This seems like a regression in terms of separating mechanism and policy.
We have several access control systems available (SELinux, at least) which
can implement this functionality with existing mechanisms using dynamic
policy.
I'm concerned about the long term architectural impact of a prol
Kees Cook wrote:
> So I sent this LSM as one I\'d been waiting
> for stacking on. Essentially, I\'m breaking the catch-22 by sending
> this. I\'d like it to get into the tree so we don\'t have a catch-22
> about stacking any more. :)
I\'m also trying to break the catch-22 by sending KPortReserve.
On Wed, Oct 16, 2013 at 2:42 PM, Casey Schaufler wrote:
> On 10/16/2013 1:47 PM, Tetsuo Handa wrote:
>> Kees Cook wrote:
>>> Any update on this? It'd be nice to have it in linux-next.
>> What was the conclusion at LSS about multiple concurrent LSM support?
>> If we agreed to merge multiple concurr
On 10/16/2013 1:47 PM, Tetsuo Handa wrote:
> Kees Cook wrote:
>> Any update on this? It'd be nice to have it in linux-next.
> What was the conclusion at LSS about multiple concurrent LSM support?
> If we agreed to merge multiple concurrent LSM support, there will be nothing
> to
> prevent this mod
Kees Cook wrote:
> Any update on this? It'd be nice to have it in linux-next.
What was the conclusion at LSS about multiple concurrent LSM support?
If we agreed to merge multiple concurrent LSM support, there will be nothing to
prevent this module from merging.
--
To unsubscribe from this list: se
Hi James,
On Mon, Sep 23, 2013 at 06:45:35PM -0700, Kees Cook wrote:
> [+rusty]
>
> On Mon, Sep 23, 2013 at 6:28 PM, James Morris wrote:
> > On Tue, 24 Sep 2013, James Morris wrote:
> >
> >> On Fri, 20 Sep 2013, Kees Cook wrote:
> >>
> >> > This LSM enforces that modules must all come from the s
On Fri, Oct 04, 2013 at 06:31:42AM +0900, Tetsuo Handa wrote:
> Kees Cook wrote:
> > +static int modpin_load_module(struct file *file)
> > +{
> > + struct dentry *module_root;
> > +
> > + if (!file) {
> > + if (!modpin_enforced) {
> > + report_load_module(NULL, "old-
Kees Cook wrote:
> +static int modpin_load_module(struct file *file)
> +{
> + struct dentry *module_root;
> +
> + if (!file) {
> + if (!modpin_enforced) {
> + report_load_module(NULL, "old-api-pinning-ignored");
> + return 0;
> + }
> +
> +
On Mon, Sep 23, 2013 at 06:45:35PM -0700, Kees Cook wrote:
> [+rusty]
>
> On Mon, Sep 23, 2013 at 6:28 PM, James Morris wrote:
> > On Tue, 24 Sep 2013, James Morris wrote:
> >
> >> On Fri, 20 Sep 2013, Kees Cook wrote:
> >>
> >> > This LSM enforces that modules must all come from the same filesys
[+rusty]
On Mon, Sep 23, 2013 at 6:28 PM, James Morris wrote:
> On Tue, 24 Sep 2013, James Morris wrote:
>
>> On Fri, 20 Sep 2013, Kees Cook wrote:
>>
>> > This LSM enforces that modules must all come from the same filesystem,
>> > with the expectation that such a filesystem is backed by a read-o
On Tue, 24 Sep 2013, James Morris wrote:
> On Fri, 20 Sep 2013, Kees Cook wrote:
>
> > This LSM enforces that modules must all come from the same filesystem,
> > with the expectation that such a filesystem is backed by a read-only
> > device such as dm-verity or CDROM. This allows systems that ha
On Fri, 20 Sep 2013, Kees Cook wrote:
> This LSM enforces that modules must all come from the same filesystem,
> with the expectation that such a filesystem is backed by a read-only
> device such as dm-verity or CDROM. This allows systems that have a
> verified or unchanging filesystem to enforce
This LSM enforces that modules must all come from the same filesystem,
with the expectation that such a filesystem is backed by a read-only
device such as dm-verity or CDROM. This allows systems that have a
verified or unchanging filesystem to enforce module loading restrictions
without needing to
23 matches
Mail list logo
