Quoting Andrew Morgan ([EMAIL PROTECTED]):
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Dolding wrote:
On 11/1/07, Casey Schaufler [EMAIL PROTECTED] wrote:
--- Peter Dolding [EMAIL PROTECTED] wrote:
Posix capabilities predate SELinux. SELinux is not interested in
Posix
Tetsuo Handa wrote:
I think there are two other problems regarding LSM.
(1) There is only one struct security_ops structure in the system.
(2) There is only one void *security field in struct task_struct.
Years ago, there was only one MAC implementation (i.e. SELinux)
in the mainline
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Dolding wrote:
On 11/1/07, Casey Schaufler [EMAIL PROTECTED] wrote:
--- Peter Dolding [EMAIL PROTECTED] wrote:
Posix capabilities predate SELinux. SELinux is not interested in
Posix capabilities.
But no IBM had to do it.
Err, no. It was
On 11/1/07, David Newall [EMAIL PROTECTED] wrote:
Jan Engelhardt wrote:
On Nov 1 2007 12:51, Peter Dolding wrote:
This is above me doing code. No matter how many fixes I do to the
core that will not fix dysfunction in the LSM section. Strict
policies on fixing the main security model
On Nov 1 2007 12:51, Peter Dolding wrote:
This is above me doing code. No matter how many fixes I do to the
core that will not fix dysfunction in the LSM section. Strict
policies on fixing the main security model will be required.
If there is no one wanting to fix the existing code, then the
Jan Engelhardt wrote:
On Nov 1 2007 12:51, Peter Dolding wrote:
This is above me doing code. No matter how many fixes I do to the
core that will not fix dysfunction in the LSM section. Strict
policies on fixing the main security model will be required.
If there is no one wanting to
On 10/31/07, Crispin Cowan [EMAIL PROTECTED] wrote:
Peter Dolding wrote:
Lets end the bitrot. Start having bits go into the main OS security
features where they should be.
Linus categorically rejected this idea, several times, very clearly.
He did so because the security community
2007/10/31, Crispin Cowan [EMAIL PROTECTED]:
Peter Dolding wrote:
Lets end the bitrot. Start having bits go into the main OS security
features where they should be.
Linus categorically rejected this idea, several times, very clearly.
He did so because the security community cannot agree
The Clear and Important thing is there is already a single security framework.
The single security framework is the security that exists when no LSM
is loaded. It turns out the more I look most of my model already
exists just not being used effectively. There is a capabilities frame
work at
On 11/1/07, Casey Schaufler [EMAIL PROTECTED] wrote:
--- Peter Dolding [EMAIL PROTECTED] wrote:
Improvements to the single security framework are getting over looked.
Please post proposed patches.
I would have personally though selinux would have done Posix file
capabilities as a
On 10/25/2007 10:42 AM, Casey Schaufler wrote:
I agree that security code does need to provide security. What we
need to get away from is the automatic attacks that are based on 20th
century computer system assumptions. Things like name based access
control is rediculous, and a module can't be
Jan Engelhardt wrote:
Apparmor tutorial (beats any FAQ at first):
ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi
Thanks for the high praise. Unfortunately that FTP site seems to not be
working. Some alternatives:
* My personal copy of the above video
On Thu, 2007-10-25 at 09:04 -0700, Ray Lee wrote:
On 10/25/07, Bernd Petrovitsch [EMAIL PROTECTED] wrote:
On Mit, 2007-10-24 at 17:35 -0700, Ray Lee wrote:
[]
Key-based masterlocks are easily broken with freon, and their combo
locks are easily brute-forced in about ten minutes. Yet,
--- Jan Engelhardt [EMAIL PROTECTED] wrote:
(please do not drop Cc, or I would have lost this thread part if I had
not been on lkml. And sometimes I am not because of the volume. Thanks.)
On Oct 30 2007 15:13, Peter Dolding wrote:
On 10/30/07, Crispin Cowan [EMAIL PROTECTED] wrote:
On 10/31/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Wed, 31 Oct 2007, Peter Dolding wrote:
MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules are
applied over using Selinux rules. This is just the way it is stacking LSM's
is Just not healthy you always risk on
--- Peter Dolding [EMAIL PROTECTED] wrote:
Lets end the bitrot. Start having bits go into the main OS security
features where they should be.
Gawd. Sorry, but we lost that argument in 1986 and the situation
hasn't changed a bit since. Most people just don't want what we're
selling. Do you
Peter Dolding wrote:
Lets end the bitrot. Start having bits go into the main OS security
features where they should be.
Linus categorically rejected this idea, several times, very clearly.
He did so because the security community cannot agree on a
one-true-standard for what that OS
On Thu, October 25, 2007 02:42, Casey Schaufler wrote:
I agree that security code does need to provide security. What we
need to get away from is the automatic attacks that are based on 20th
century computer system assumptions. Things like name based access
control is rediculous, and a module
On Mon, October 29, 2007 11:24, Crispin Cowan wrote:
Thus IMHO it may be a good idea to instead of a maintainer for LSM
modules as proposed, alternatively a maintainer for each formal model
may be more appropriate. This also would require module builders to
first
think about what formal
--- Rob Meijer [EMAIL PROTECTED] wrote:
* The proposal only allows a single implementation of each formal
model. In theory, theory is just like practice, but in practice it
is not. SMACK and SELinux follow substantially similar formal
models (not exactly the same)
On 10/25/2007 9:41 AM, Chris Wright wrote:
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
Do other people want to stand up and be LSM maintainers in the sense
that they also end up being informed members who can also stand up for new
modules and help merge them, rather than just push the existing
On 10/30/07, Crispin Cowan [EMAIL PROTECTED] wrote:
Ah! So the proposal really is to have an LSM maintainer for each
family of models, acting as a resource and arbiter for modules in a class.
I see it a little bit different one LSM maintainer for the lot of
modules who kicks the ass's of thoses
Hi!
but require unreasonable interface changes. As people who care
about security (y'all who are only from the LKML are excused) it
is our obligation to look beyond the preconceived notions of what
is and isn't secure. Security is subjective. It's how you feel
about it.
sarcasmHmm. So lets
Hi!
The idea that poor security is worse than no security is fallacious,
and not backed up by common experience.
There is a ton of evidence both in computing and outside of it which
shows that poor security can be very much worse than no security at all.
(So, I take it that you
@vger.kernel.org;
Jan Engelhardt; Linus Torvalds; Andreas Gruenbacher; Thomas Fricaccia;
Jeremy Fitzhardinge; James Morris; Crispin Cowan; Giacomo Catenazzi
Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to
static interface)
Hi!
The idea that poor security is worse than
On Sun, 28 Oct 2007 15:08:56 -0700
Crispin Cowan [EMAIL PROTECTED] wrote:
To reject an LSM for providing bad security, IMHO you should have to
show how it is possible to subvert the self-stated goals of that LSM.
Complaints that the LSM fails to meet some goal outside of its stated
purpose is
Hello.
Simon Arlott wrote:
I currently have an LSM that only handles permissions for socket_bind
and socket_listen, I load it and then capability as secondary on
boot - but now I can't because the LSM framework is now just the LS
framework.
I think there are two other problems regarding LSM.
On Oct 25 2007 19:56, Greg KH wrote:
I'm trying to compile a list of all known external modules and drivers
and work to get them included in the main kernel tree to help prevent
these kinds of things. If you know of any that are not on the list at:
On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
Am 25.10.2007 00:31 schrieb Adrian Bunk:
Generally, the goal is to get external modules included into the kernel.
[...] even though it might sound harsh breaking
external
On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
I'm trying to compile a list of all known external modules and drivers
and work to get them included in the main kernel tree to help prevent
these kinds of things. If you know
On Fri, Oct 26, 2007 at 09:09:05AM +0200, Jan Engelhardt wrote:
On Oct 25 2007 19:56, Greg KH wrote:
I'm trying to compile a list of all known external modules and drivers
and work to get them included in the main kernel tree to help prevent
these kinds of things. If you know of any that
On 26/10/07 16:58, Greg KH wrote:
On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
I'm trying to compile a list of all known external modules and drivers
and work to get them included in the main kernel tree to help prevent
On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
Am 25.10.2007 00:31 schrieb Adrian Bunk:
Generally, the goal is to get external modules included into the
On Mit, 2007-10-24 at 17:35 -0700, Ray Lee wrote:
[]
Key-based masterlocks are easily broken with freon, and their combo
locks are easily brute-forced in about ten minutes. Yet, I'll still
use them to lock up my bike and garage.
The question is what the security threat is and the value of
On Wed, October 24, 2007 22:02, David P. Quigley wrote:
Apparmor wants to lock down some application, it gives the application
access to a particular port, and the minimal set of privileges needed to
execute the application. Since Apparmor is easy to use (note the
quotes are to indicate they
On Wed, October 24, 2007 23:31, Adrian Bunk wrote:
On Wed, Oct 24, 2007 at 07:11:17PM +0100, Simon Arlott wrote:
On 24/10/07 13:55, Adrian Bunk wrote:
On Wed, Oct 24, 2007 at 12:50:29PM +0100, Simon Arlott wrote:
I currently have an LSM that only handles permissions for socket_bind
and
On 10/25/07, Bernd Petrovitsch [EMAIL PROTECTED] wrote:
On Mit, 2007-10-24 at 17:35 -0700, Ray Lee wrote:
[]
Key-based masterlocks are easily broken with freon, and their combo
locks are easily brute-forced in about ten minutes. Yet, I'll still
use them to lock up my bike and garage.
On Thu, 25 Oct 2007 09:04:57 -0700
Ray Lee [EMAIL PROTECTED] wrote:
Security is not an all or nothing game, it's layers. And we have to
make sure that the layers are usable without taking a course from the
NSA. I'd love to see a poll of the kernel development community to
find out how many
On 10/24/07, Alan Cox [EMAIL PROTECTED] wrote:
The idea that poor security is worse than no security is fallacious,
and not backed up by common experience.
There is a ton of evidence both in computing and outside of it which
shows that poor security can be very much worse than no security
There is a ton of evidence both in computing and outside of it which
shows that poor security can be very much worse than no security at all.
(So, I take it that you *don't* lock your bike up, as poor security is
worse than none?)
On the contrary because I know it is not secure I would
Am 25.10.2007 00:31 schrieb Adrian Bunk:
Generally, the goal is to get external modules included into the kernel.
[...] even though it might sound harsh breaking
external modules and thereby making people aware that their code should
get into the kernel is IMHO a positive point.
This
On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
Am 25.10.2007 00:31 schrieb Adrian Bunk:
Generally, the goal is to get external modules included into the kernel.
[...] even though it might sound harsh breaking
external modules and thereby making people aware that their code
On 24/10/07 13:55, Adrian Bunk wrote:
On Wed, Oct 24, 2007 at 12:50:29PM +0100, Simon Arlott wrote:
I currently have an LSM that only handles permissions for socket_bind
and socket_listen, I load it and then capability as secondary on
boot - but now I can't because the LSM framework is now
On Oct 24 2007 19:11, Simon Arlott wrote:
* (I've got a list of access rules which are scanned in order until one of
them matches, and an array of one bit for every port for per-port default
allow/deny - although the latter could be removed.
http://svn.lp0.eu/simon/portac/trunk/)
Besides the
Jan Engelhardt wrote:
On Oct 24 2007 19:11, Simon Arlott wrote:
* (I've got a list of access rules which are scanned in order until one of
them matches, and an array of one bit for every port for per-port default
allow/deny - although the latter could be removed.
On Wed, 2007-10-24 at 21:04 +0200, Jan Engelhardt wrote:
On Oct 24 2007 19:59, Simon Arlott wrote:
On 24/10/07 19:51, Jan Engelhardt wrote:
On Oct 24 2007 19:11, Simon Arlott wrote:
* (I've got a list of access rules which are scanned in order until one of
them matches, and an array of
On Oct 24 2007 18:02, David P. Quigley wrote:
But an LSM needs to _explicitly_ call the next LSM's function. No
one (just a minimal grep in linux-2.6/security/) besides SELinux
does that today. So while you could load AppArmor ontop of
MultiAdm, it would never be invoked. This is what is
Its the way you cut. Splitting up into modules is not exactly going
to work alone.
I basically cover it in Re: LSM and Containers.
Where you have different parts enforcing the permissions. Only one
module allocating them in a zone at a time. Yes just like posix file
caps I want the enforcing
On Wed, Oct 24, 2007 at 03:58:02PM -0700, Casey Schaufler wrote:
--- Adrian Bunk [EMAIL PROTECTED] wrote:
...
There are other points in this thread that might or might not warrant
making LSM modular again, but even though it might sound harsh breaking
external modules and thereby
* Casey Schaufler ([EMAIL PROTECTED]) wrote:
And don't give me the old LKML is a tough crowd feldercarb.
Security modules have been much worse. Innovation, even in
security, is a good thing and treating people harshly, even
for their own good, is an impediment to innovation.
I agree that
On 10/24/07, Chris Wright [EMAIL PROTECTED] wrote:
* Casey Schaufler ([EMAIL PROTECTED]) wrote:
And don't give me the old LKML is a tough crowd feldercarb.
Security modules have been much worse. Innovation, even in
security, is a good thing and treating people harshly, even
for their own
I have different deal breakers.
If a LSM is something simple/commonly required it should be made like
posix file capability's provided to all to use. Sorry to say I see
the file protection in apparmor as something everyone should be able
to use at will like posix file capability's. All
--- Chris Wright [EMAIL PROTECTED] wrote:
* Casey Schaufler ([EMAIL PROTECTED]) wrote:
And don't give me the old LKML is a tough crowd feldercarb.
Security modules have been much worse. Innovation, even in
security, is a good thing and treating people harshly, even
for their own good,
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
Do other people want to stand up and be LSM maintainers in the sense
that they also end up being informed members who can also stand up for new
modules and help merge them, rather than just push the existing one(s)?
Chris? Casey? Crispin?
Stephen
The idea that poor security is worse than no security is fallacious,
and not backed up by common experience.
There is a ton of evidence both in computing and outside of it which
shows that poor security can be very much worse than no security at all.
In particular stuff which makes users think
On Thu, 25 Oct 2007, Alan Cox wrote:
The idea that poor security is worse than no security is fallacious,
and not backed up by common experience.
There is a ton of evidence both in computing and outside of it which
shows that poor security can be very much worse than no security at all.
In
On Wed, 24 Oct 2007 17:41:28 -0700
Chris Wright [EMAIL PROTECTED] wrote:
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
Do other people want to stand up and be LSM maintainers in the
sense that they also end up being informed members who can also
stand up for new modules and help merge them,
On Oct 24, 2007, at 17:37:04, Serge E. Hallyn wrote:
The scariest thing to consider is programs which don't
appropriately handle failure. So I don't know, maybe the system
runs a remote logger to which the multiadm policy gives some extra
privs, but now the portac module prevents it from
58 matches
Mail list logo
