Roberts, William C wrote:
From: owner-linux-security-mod...@vger.kernel.org [mailto:owner-linux-
security-mod...@vger.kernel.org] On Behalf Of Joshua Brindle
Sent: Tuesday, September 1, 2015 7:13 AM
To: Paul Moore
Cc: Luis R. Rodriguez; Takashi Iwai; Ming Lei; David Howells; Peter Jones;
seli
Paul Moore wrote:
Yes, there are lots of way we could solve the signed policy format
issue, I just don't have one in mind at this moment. Also, to be
honest, there are enough limitations to signing SELinux policies that
this isn't very high onmy personal SELinux priority list.
The fact
Roberts, William C wrote:
From: owner-linux-security-mod...@vger.kernel.org [mailto:owner-linux-
security-mod...@vger.kernel.org] On Behalf Of Joshua Brindle
Sent: Tuesday, September 1, 2015 7:13 AM
To: Paul Moore
Cc: Luis R. Rodriguez; Takashi Iwai; Ming Lei; David Howells; Peter Jones;
seli
Paul Moore wrote:
Yes, there are lots of way we could solve the signed policy format
issue, I just don't have one in mind at this moment. Also, to be
honest, there are enough limitations to signing SELinux policies that
this isn't very high onmy personal SELinux priority list.
The fact
Victor Porton wrote:
I propose to create a new NetFilter table dedicated to rules created
programmatically (not by explicit admin's iptables command).
Otherwise an admin could be tempted to say `iptables -F security` which would
probably break rules created for example by sandboxing software
Victor Porton wrote:
I propose to create a new NetFilter table dedicated to rules created
programmatically (not by explicit admin's iptables command).
Otherwise an admin could be tempted to say `iptables -F security` which would
probably break rules created for example by sandboxing software
Eamon Walsh wrote:
This patch removes the requirement that the new and related object
types differ in order to polyinstantiate by MLS level. This allows
MLS polyinstantiation to occur in the absence of explicit type_member
rules or when the type has not changed.
Potential users of this
Eamon Walsh wrote:
This patch removes the requirement that the new and related object
types differ in order to polyinstantiate by MLS level. This allows
MLS polyinstantiation to occur in the absence of explicit type_member
rules or when the type has not changed.
Potential users of this
Kyle Moffett wrote:
On Nov 24, 2007, at 22:36:43, Crispin Cowan wrote:
Kyle Moffett wrote:
Actually, a fully-secured strict-mode SELinux system will have no
unconfined_t processes; none of my test systems have any. Generally
"unconfined_t" is used for situations similar to what AppArmor was
Kyle Moffett wrote:
On Nov 24, 2007, at 22:36:43, Crispin Cowan wrote:
Kyle Moffett wrote:
Actually, a fully-secured strict-mode SELinux system will have no
unconfined_t processes; none of my test systems have any. Generally
unconfined_t is used for situations similar to what AppArmor was
Casey Schaufler wrote:
--- Crispin Cowan <[EMAIL PROTECTED]> wrote:
Dr. David Alan Gilbert wrote:
...
Can you explain why you want a non-privileged user to be able to edit
policy? I would like to better understand the problem here.
Note that John Johansen is also interested in allowing
Casey Schaufler wrote:
--- Crispin Cowan [EMAIL PROTECTED] wrote:
Dr. David Alan Gilbert wrote:
...
Can you explain why you want a non-privileged user to be able to edit
policy? I would like to better understand the problem here.
Note that John Johansen is also interested in allowing
Joshua Brindle wrote:
Casey Schaufler wrote:
From: Paul Moore <[EMAIL PROTECTED]>
Add a new set of configuration functions to the NetLabel/LSM API so that
LSMs can perform their own configuration of the NetLabel subsystem
without
relying on assistance from userspace.
I'm
Casey Schaufler wrote:
From: Paul Moore <[EMAIL PROTECTED]>
Add a new set of configuration functions to the NetLabel/LSM API so that
LSMs can perform their own configuration of the NetLabel subsystem without
relying on assistance from userspace.
I'm still not receiving the actual patch email
Casey Schaufler wrote:
From: Paul Moore [EMAIL PROTECTED]
Add a new set of configuration functions to the NetLabel/LSM API so that
LSMs can perform their own configuration of the NetLabel subsystem without
relying on assistance from userspace.
I'm still not receiving the actual patch email
Joshua Brindle wrote:
Casey Schaufler wrote:
From: Paul Moore [EMAIL PROTECTED]
Add a new set of configuration functions to the NetLabel/LSM API so that
LSMs can perform their own configuration of the NetLabel subsystem
without
relying on assistance from userspace.
I'm still not receiving
Casey Schaufler wrote:
The Smack patch and Paul Moore's netlabel API patch,
together for 2.6.24-rc1. Paul's changes are identical
to the previous posting, but it's been a while so they're
here again.
The sole intent of change has been to address locking
and/or list processing issues. Please
Casey Schaufler wrote:
The Smack patch and Paul Moore's netlabel API patch,
together for 2.6.24-rc1. Paul's changes are identical
to the previous posting, but it's been a while so they're
here again.
The sole intent of change has been to address locking
and/or list processing issues. Please
Casey Schaufler wrote:
The Smack patch and Paul Moore's netlabel API patch,
together for 2.6.24-rc1. Paul's changes are identical
to the previous posting, but it's been a while so they're
here again.
The sole intent of change has been to address locking
and/or list processing issues. Please
Casey Schaufler wrote:
The Smack patch and Paul Moore's netlabel API patch,
together for 2.6.24-rc1. Paul's changes are identical
to the previous posting, but it's been a while so they're
here again.
The sole intent of change has been to address locking
and/or list processing issues. Please
Andi Kleen wrote:
- hm, netlabels. Who might be a suitable person to review that code?
Seems that Paul Moore is the man. Maybe he'd be interested in taking a
look over it (please?)
I personally consider these IP options it uses to be pretty useless. Who could
ever use that without
Andi Kleen wrote:
- hm, netlabels. Who might be a suitable person to review that code?
Seems that Paul Moore is the man. Maybe he'd be interested in taking a
look over it (please?)
I personally consider these IP options it uses to be pretty useless. Who could
ever use that without
Kyle Moffett wrote:
On Aug 12, 2007, at 15:41:46, Casey Schaufler wrote:
Your boolean solution requires more forthought than the Smack rule
solution, but I'll give it to you once you've fleshed out your "##"
lines.
How does it require more forethought? When I want to turn it on, I
write
Kyle Moffett wrote:
On Aug 12, 2007, at 15:41:46, Casey Schaufler wrote:
Your boolean solution requires more forthought than the Smack rule
solution, but I'll give it to you once you've fleshed out your ##
lines.
How does it require more forethought? When I want to turn it on, I
write and
[EMAIL PROTECTED] wrote:
On Thu, 21 Jun 2007, Joshua Brindle wrote:
Lars Marowsky-Bree wrote:
On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote:
> Um, no. It might not be able to directly open files via that
path, but
> showing that it can never read o
Lars Marowsky-Bree wrote:
On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote:
Um, no. It might not be able to directly open files via that path, but
showing that it can never read or write your mail is a rather different
matter.
Yes. Your use case is different than
Lars Marowsky-Bree wrote:
On 2007-06-21T16:59:54, Stephen Smalley [EMAIL PROTECTED] wrote:
snip
Um, no. It might not be able to directly open files via that path, but
showing that it can never read or write your mail is a rather different
matter.
Yes. Your use case is different than
[EMAIL PROTECTED] wrote:
On Thu, 21 Jun 2007, Joshua Brindle wrote:
Lars Marowsky-Bree wrote:
On 2007-06-21T16:59:54, Stephen Smalley [EMAIL PROTECTED] wrote:
snip
Um, no. It might not be able to directly open files via that
path, but
showing that it can never read or write your
Casey Schaufler wrote:
--- James Morris <[EMAIL PROTECTED]> wrote:
On Fri, 15 Jun 2007, Casey Schaufler wrote:
--- James Morris <[EMAIL PROTECTED]> wrote:
On my system, it takes about 1.2 seconds to label a fully checked out
kernel source tree with ~23,000 files in this
Casey Schaufler wrote:
--- James Morris [EMAIL PROTECTED] wrote:
On Fri, 15 Jun 2007, Casey Schaufler wrote:
--- James Morris [EMAIL PROTECTED] wrote:
On my system, it takes about 1.2 seconds to label a fully checked out
kernel source tree with ~23,000 files in this manner
Crispin Cowan wrote:
[EMAIL PROTECTED] wrote:
On Fri, 8 Jun 2007, Greg KH wrote:
I still want to see a definition of the AA "model" that we can then use
to try to implement using whatever solution works best. As that seems
to be missing the current argument of if AA can or can not be
Crispin Cowan wrote:
[EMAIL PROTECTED] wrote:
On Fri, 8 Jun 2007, Greg KH wrote:
I still want to see a definition of the AA model that we can then use
to try to implement using whatever solution works best. As that seems
to be missing the current argument of if AA can or can not be
[EMAIL PROTECTED] wrote:
On Sat, 9 Jun 2007, Sean wrote:
what SELinux cannot do is figure out what label to assign a new file.
Nit: SELinux figures out what to label new files fine, just not based on
the name. This works in most cases, eg., when user_t creates a file in
/tmp it becomes
[EMAIL PROTECTED] wrote:
On Sat, 9 Jun 2007, Sean wrote:
snip
what SELinux cannot do is figure out what label to assign a new file.
Nit: SELinux figures out what to label new files fine, just not based on
the name. This works in most cases, eg., when user_t creates a file in
/tmp it
Crispin Cowan wrote:
David Wagner wrote:
James Morris wrote:
[...] you can change the behavior of the application and then bypass
policy entirely by utilizing any mechanism other than direct filesystem
access: IPC, shared memory, Unix domain sockets, local IP networking,
remote
Crispin Cowan wrote:
David Wagner wrote:
James Morris wrote:
[...] you can change the behavior of the application and then bypass
policy entirely by utilizing any mechanism other than direct filesystem
access: IPC, shared memory, Unix domain sockets, local IP networking,
remote
Crispin Cowan wrote:
David Wagner wrote:
James Morris wrote:
[...] you can change the behavior of the application and then bypass
policy entirely by utilizing any mechanism other than direct filesystem
access: IPC, shared memory, Unix domain sockets, local IP networking,
remote
Crispin Cowan wrote:
David Wagner wrote:
James Morris wrote:
[...] you can change the behavior of the application and then bypass
policy entirely by utilizing any mechanism other than direct filesystem
access: IPC, shared memory, Unix domain sockets, local IP networking,
remote
Rob Meijer wrote:
On Tue, April 17, 2007 23:55, Karl MacMillan wrote:
On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
On Mon, 16 Apr 2007, John Johansen wrote:
Label-based security (exemplified by SELinux, and its predecessors in
MLS systems) attaches security policy to
Rob Meijer wrote:
On Tue, April 17, 2007 23:55, Karl MacMillan wrote:
On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
On Mon, 16 Apr 2007, John Johansen wrote:
Label-based security (exemplified by SELinux, and its predecessors in
MLS systems) attaches security policy to
40 matches
Mail list logo
