lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0708181902460.22470@asgard.lang.hm>
Date:	Sat, 18 Aug 2007 19:03:06 -0700 (PDT)
From:	david@...g.hm
To:	Alan <alan@...eserver.org>
cc:	Kyle Moffett <mrmacman_g4@....com>,
	Marc Perkel <mperkel@...oo.com>, Valdis.Kletnieks@...edu,
	Michael Tharp <gxti@...tiallystapled.com>,
	LKML Kernel <linux-kernel@...r.kernel.org>,
	Lennart Sorensen <lsorense@...lub.uwaterloo.ca>
Subject: Re: Thinking outside the box on file systems

On Sat, 18 Aug 2007, Alan wrote:

> On Wed, 2007-08-15 at 13:22 -0400, Kyle Moffett wrote:
>> On Aug 15, 2007, at 13:09:31, Marc Perkel wrote:
>>> The idea is that people have permissions - not files.  By people I
>>> mean users, groups, managers, applications
>>> etc. One might even specify that there are no permission
>>> restrictions at all. Part of the process would be that the kernel
>>> load what code it will use for the permission system. It might even
>>> be a little perl script you write.
>>>
>>> Also - you aren't even giving permission to access files. It's
>>> permission to access name patterns. One could apply REGEX masks to
>>> names to determine permissions. So if you have permission to the
>>> name you have permission to the file.
>>
>> Please excuse me, I'm going to go stand over in the corner for a minute.
>>
>> *hahahahahaa hahahahahaaa hahaa hoo hee snicker sniff*
>>
>> *wanders back into the conversation*
>>
>> Sorry about that, pardon me.
>>
>> I suspect you will find it somewhat hard to convince *anybody* on
>> this list to put either a regex engine or a Perl interpreter into the
>> kernel.  I doubt you could even get a simple shell-style pattern
>> matcher in.  First of all, both of the former chew up enormous gobs
>> of stack space *AND* they're NP-complete.  You just can't do such
>> matching even in polynomial time, let alone something that scales
>> appropriately for an OS kernel like, say, O(log(n)).
>
> Already been done.  Take a look at "AppArmor" aka "Immunix".

don't forget the ACPI interpreter.

David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ