then need to define a corresponding hook function
to call the secondary module? Otherwise, it will fall back to the dummy
implementation and stacking selinux + capabilities with file caps won't
yield the right behavior.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list
y load is done
by /sbin/init in most distros that support selinux, although I'd prefer
to do it earlier from the initramfs (the Fedora folks didn't like that
idea though at the time, so /sbin/init got patched instead - but that
was back in 2003, so maybe things have changed).
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
I'd prefer
to do it earlier from the initramfs (the Fedora folks didn't like that
idea though at the time, so /sbin/init got patched instead - but that
was back in 2003, so maybe things have changed).
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line
olicy.
>
> (rpm -qa selinux-policy-*
> selinux-policy-devel-2.6.4-25.fc7
> selinux-policy-targeted-2.6.4-25.fc7)
>
> I will add this as a regression unless Linus says "Fsck it! We don't care
> about compatibility"
Agreed, it needs to be fixed in the netlabel code.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-policy-devel-2.6.4-25.fc7
selinux-policy-targeted-2.6.4-25.fc7)
I will add this as a regression unless Linus says Fsck it! We don't care
about compatibility
Agreed, it needs to be fixed in the netlabel code.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send
ile descriptor or by
pathname?
And what does this mean for a process that has "changed hats"? Which
might not be authorized to access the file anymore, even via an already
opened descriptor.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line &quo
p(name, XATTR_NAME_CAPS)) {
> + if (!capable(CAP_SETFCAP))
> + return -EPERM;
> + } else if (!capable(CAP_SYS_ADMIN)) {
> + /* A different attribute in the security
> +
recognize, so just check the
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
not be authorized to access the file anymore, even via an already
opened descriptor.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
On Thu, 2007-06-28 at 13:22 -0500, Serge E. Hallyn wrote:
> This fixes a shortcoming of the cap_setfcap patch I sent earlier,
> pointed out by Stephen Smalley.
>
> Seems to compile and boot on my little systems.
>
> thanks,
> -serge
>
> >From d729000b922a2877a48ce
On Thu, 2007-06-28 at 13:22 -0500, Serge E. Hallyn wrote:
This fixes a shortcoming of the cap_setfcap patch I sent earlier,
pointed out by Stephen Smalley.
Seems to compile and boot on my little systems.
thanks,
-serge
From d729000b922a2877a48ce2b5a03a9366d8c65d04 Mon Sep 17 00:00:00
security_ops);
I think you want to eliminate that last export too, by taking the
security hooks that are called by modules into out-of-line wrapper
functions in security.c rather than directly referencing security_ops.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this l
-of-line wrapper
functions in security.c rather than directly referencing security_ops.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
On Fri, 2007-06-22 at 09:22 -0400, Stephen Smalley wrote:
> On Fri, 2007-06-22 at 14:54 +0200, Lars Marowsky-Bree wrote:
> > On 2007-06-22T08:41:51, Stephen Smalley <[EMAIL PROTECTED]> wrote:
> > > Sorry, do you mean the "server" as in the "server sy
On Fri, 2007-06-22 at 14:54 +0200, Lars Marowsky-Bree wrote:
> On 2007-06-22T08:41:51, Stephen Smalley <[EMAIL PROTECTED]> wrote:
> > Sorry, do you mean the "server" as in the "server system" or as in the
> > "server daemon"? For the former, I
On Fri, 2007-06-22 at 14:42 +0200, Lars Marowsky-Bree wrote:
> On 2007-06-22T07:53:47, Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > > No the "incomplete" mediation does not flow from the design. We have
> > > deliberately focused on doing the necessar
On Fri, 2007-06-22 at 13:37 +0200, Lars Marowsky-Bree wrote:
> On 2007-06-22T07:19:39, Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > > > Or can access the data under a different path to which their profile
> > > > does give them access, whether
cess
> and POSIX.1e capabilities" and that list got extended as AA got new
> confinement features, would that address your issue?
That would certainly help, although one might quibble with the use of
the word "confinement" at all wrt AppArmor (it has a long-established
technical me
On Fri, 2007-06-22 at 01:06 -0700, John Johansen wrote:
> On Thu, Jun 21, 2007 at 04:59:54PM -0400, Stephen Smalley wrote:
> > On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote:
> > > On 2007-06-21T15:42:28, James Morris <[EMAIL PROTECTED]> wrote:
> > >
alicious or flawed programs. They should also be useful for
enabling a single system to be used by users with differing security
authorizations to access multiple kinds of information with differing
security requirements without compromising those security requirements.
--
Stephen Smalley
Nationa
On Thu, 2007-06-21 at 23:17 +0200, Lars Marowsky-Bree wrote:
> On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > Or can access the data under a different path to which their profile
> > does give them access, whether in its final destination or in
On Thu, 2007-06-21 at 23:17 +0200, Lars Marowsky-Bree wrote:
On 2007-06-21T16:59:54, Stephen Smalley [EMAIL PROTECTED] wrote:
Or can access the data under a different path to which their profile
does give them access, whether in its final destination or in some
temporary file processed
authorizations to access multiple kinds of information with differing
security requirements without compromising those security requirements.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED
On Fri, 2007-06-22 at 01:06 -0700, John Johansen wrote:
On Thu, Jun 21, 2007 at 04:59:54PM -0400, Stephen Smalley wrote:
On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote:
On 2007-06-21T15:42:28, James Morris [EMAIL PROTECTED] wrote:
And now, yes, I know AA doesn't
control, and that goes
beyond even complete mediation - it requires global and persistent
protection of the data based on its properties, which requires stable
and unambiguous identifiers).
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux
On Fri, 2007-06-22 at 14:42 +0200, Lars Marowsky-Bree wrote:
On 2007-06-22T07:53:47, Stephen Smalley [EMAIL PROTECTED] wrote:
No the incomplete mediation does not flow from the design. We have
deliberately focused on doing the necessary modifications for pathname
based mediation
On Fri, 2007-06-22 at 13:37 +0200, Lars Marowsky-Bree wrote:
On 2007-06-22T07:19:39, Stephen Smalley [EMAIL PROTECTED] wrote:
Or can access the data under a different path to which their profile
does give them access, whether in its final destination or in some
temporary file
On Fri, 2007-06-22 at 14:54 +0200, Lars Marowsky-Bree wrote:
On 2007-06-22T08:41:51, Stephen Smalley [EMAIL PROTECTED] wrote:
Sorry, do you mean the server as in the server system or as in the
server daemon? For the former, I'd agree - we would want SELinux
policy applied on the server
On Fri, 2007-06-22 at 09:22 -0400, Stephen Smalley wrote:
On Fri, 2007-06-22 at 14:54 +0200, Lars Marowsky-Bree wrote:
On 2007-06-22T08:41:51, Stephen Smalley [EMAIL PROTECTED] wrote:
Sorry, do you mean the server as in the server system or as in the
server daemon? For the former, I'd
access my on-disk mail folder, it can't
> get there. (Barring bugs in programs which Mozilla is allowed to run
> unconfined, sure.)
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.
--
Stephen S
files via that path, but
showing that it can never read or write your mail is a rather different
matter.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
ification depends on a lot of factors
> (like the specific requirements - CC is just a process not a single set
> of requirements). I don't know enough to really guess.
>
> More to the point, though, the requirements in those documents are
> outdated at best. I don't think it is worth
On Fri, 2007-06-15 at 13:43 -0700, Casey Schaufler wrote:
> --- Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > On Fri, 2007-06-15 at 11:01 -0700, Casey Schaufler wrote:
> > > --- Greg KH <[EMAIL PROTECTED]> wrote:
> > >
> > >
>
On Fri, 2007-06-15 at 13:43 -0700, Casey Schaufler wrote:
--- Stephen Smalley [EMAIL PROTECTED] wrote:
On Fri, 2007-06-15 at 11:01 -0700, Casey Schaufler wrote:
--- Greg KH [EMAIL PROTECTED] wrote:
A daemon using inotify can instantly[1] detect this and label the file
at all.
Probably not - you would likely want it to be a label that can't be read
or written by anything, only relabeled by the daemon.
Karl
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
avoid relying on it for anything security-critical
naturally. And one could introduce the named type transition concept
that has been discussed in this thread without much difficulty to
selinux.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsub
transition concept
that has been discussed in this thread without much difficulty to
selinux.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
nforce". You can easily
> > get the TOMOYO Linux policy with learning mode that
> > SELinux does not have. In addition, access control mode of
> > TOMOYO Linux can be managed for every difference domain.
>
> This sounds a like like feature differences "compared" at:
> h
and fair-minded comparison.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wed, 2007-06-13 at 23:22 +0900, Toshiharu Harada wrote:
> 2007/6/13, Stephen Smalley <[EMAIL PROTECTED]>:
> > On Wed, 2007-06-13 at 17:13 +0900, Toshiharu Harada wrote:
> > > Here are examples:
> > > /bin/bash process invoked from mingetty: /sbin/mingetty
or)
> NTT DATA CORPORATION
> http://www.nttdata.co.jp/en/index.html
>
> *1) http://sourceforge.jp/projects/tomoyo/document/nsf2003-en.pdf
> *2) http://tomoyo.sourceforge.jp/
> *3) http://www.celinux.org/elc2007/
> http://tree.celinuxforum.org/CelfPubWiki/ELC2007Presentations
> *
://www.linuxsymposium.org/2007/
-
To unsubscribe from this list: send the line unsubscribe
linux-security-module in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Stephen Smalley
National Security Agency
-
To unsubscribe from
On Wed, 2007-06-13 at 23:22 +0900, Toshiharu Harada wrote:
2007/6/13, Stephen Smalley [EMAIL PROTECTED]:
On Wed, 2007-06-13 at 17:13 +0900, Toshiharu Harada wrote:
Here are examples:
/bin/bash process invoked from mingetty: /sbin/mingetty /bin/bash
/bin/bash process invoked from sshd
On Mon, 2007-06-11 at 17:55 +0200, Andreas Gruenbacher wrote:
> On Monday 11 June 2007 16:33, Stephen Smalley wrote:
> > On Mon, 2007-06-11 at 01:10 +0200, Andreas Gruenbacher wrote:
> > > On Wednesday 06 June 2007 15:09, Stephen Smalley wrote:
> > > > On Mon, 2007
On Mon, 2007-06-11 at 14:02 -0500, Serge E. Hallyn wrote:
> Quoting Andreas Gruenbacher ([EMAIL PROTECTED]):
> > On Monday 11 June 2007 16:33, Stephen Smalley wrote:
> > > On Mon, 2007-06-11 at 01:10 +0200, Andreas Gruenbacher wrote:
> > > > On Wednesday 06 June 200
On Mon, 2007-06-11 at 14:02 -0500, Serge E. Hallyn wrote:
Quoting Andreas Gruenbacher ([EMAIL PROTECTED]):
On Monday 11 June 2007 16:33, Stephen Smalley wrote:
On Mon, 2007-06-11 at 01:10 +0200, Andreas Gruenbacher wrote:
On Wednesday 06 June 2007 15:09, Stephen Smalley wrote
On Mon, 2007-06-11 at 17:55 +0200, Andreas Gruenbacher wrote:
On Monday 11 June 2007 16:33, Stephen Smalley wrote:
On Mon, 2007-06-11 at 01:10 +0200, Andreas Gruenbacher wrote:
On Wednesday 06 June 2007 15:09, Stephen Smalley wrote:
On Mon, 2007-06-04 at 16:30 +0200, Andreas Gruenbacher
On Sat, 2007-06-09 at 00:03 +0200, Andreas Gruenbacher wrote:
> On Wednesday 06 June 2007 15:26, Stephen Smalley wrote:
> > - under AA, each file may have an arbitrary set of "labels" or
> > "policies" applied to it depending on what programs are accessing i
On Mon, 2007-06-11 at 01:10 +0200, Andreas Gruenbacher wrote:
> On Wednesday 06 June 2007 15:09, Stephen Smalley wrote:
> > On Mon, 2007-06-04 at 16:30 +0200, Andreas Gruenbacher wrote:
> > > On Monday 04 June 2007 15:12, Pavel Machek wrote:
> > > > How will kernel
On Mon, 2007-06-11 at 01:10 +0200, Andreas Gruenbacher wrote:
On Wednesday 06 June 2007 15:09, Stephen Smalley wrote:
On Mon, 2007-06-04 at 16:30 +0200, Andreas Gruenbacher wrote:
On Monday 04 June 2007 15:12, Pavel Machek wrote:
How will kernel work with very long paths? I'd suspect
On Sat, 2007-06-09 at 00:03 +0200, Andreas Gruenbacher wrote:
On Wednesday 06 June 2007 15:26, Stephen Smalley wrote:
- under AA, each file may have an arbitrary set of labels or
policies applied to it depending on what programs are accessing it and
what names are being used to reference
lling cond_resched after each one. These
changes should allow preemption between the individual checks and
enable caching of the results. It may however increase the overall
time spent in the function in some cases, particularly in the cache
miss case.
The long term fix will be to take much o
case.
The long term fix will be to take much of this logic to userspace by
exporting additional state via selinuxfs, and ultimately deprecating
and eliminating this interface from the kernel.
Signed-off-by: Stephen Smalley [EMAIL PROTECTED]
---
security/selinux/avc.c | 10
define DCCP_SOCKET__NAME_CONNECT 0x0080UL
> +#define MEMPROTECT__MMAP_ZERO 0x0001UL
> diff --git a/security/selinux/include/class_to_string.h
> b/security/selinux/include/class_to_string.h
> index 3787990..e77de0e 100644
> --- a/security/selinux/
te files of multiple security contexts
in the same directory. That would further help the SEEdit folks in
emulating AA on top of SELinux, but as before, I don't get the
impression that the AA folks will ever be satisfied with such an
emulation, not because of any real requirement but merely because they
a
ade the wrong choice? If so,
why?
Just trying to understand your position better...
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.
restrictions by default under dummy/capability, but restrict it
by default to 64k if selinux is enabled. Then we can use policy to
grant it as needed to the specific programs.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe linux-ke
policies with such rules, and I'd prefer
to isolate especially security-sensitive permissions in distinct classes
(and we are running out of room in process class).
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
lity code.
The only tricky part there is retaining the support for falling back on
capabilities upon runtime disable of selinux by /sbin/init.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [
on
capabilities upon runtime disable of selinux by /sbin/init.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
-sensitive permissions in distinct classes
(and we are running out of room in process class).
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
policy to
grant it as needed to the specific programs.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
to understand your position better...
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
real requirement but merely because they
are tied to their implementation specifics.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
existing behavior). It could break binaries, albeit potentially insecure
Agreed - DOSemu type apps and lrmi need to map at zero for vm86
And so it shall be!
Signed-off-by: Eric Paris [EMAIL PROTECTED]
With the fix already noted by James,
Acked-by: Stephen Smalley [EMAIL PROTECTED]
Note
f in memory vs.
performance introduced by the patches to reduce the avtab memory use
introduced in 2.6.14. In the common case, you don't see it due to the
AVC caching the results of compute_av but security_get_user_sids doesn't
go through the AVC. That's harder to fix.
I think we can try refactoring se
. In the common case, you don't see it due to the
AVC caching the results of compute_av but security_get_user_sids doesn't
go through the AVC. That's harder to fix.
I think we can try refactoring security_get_user_sids and see how much
that helps.
--
Stephen Smalley
National Security Agency
out what to do with
> this work.
return-eperm-not-echild-on-security_task_wait-failure.patch should be
merged - it is effectively a bug fix.
On the file capabilities support, have any of the filesystem folks
(cc'd) looked at the code yet?
--
Stephen Smalley
National Security Agency
-
T
with
this work.
return-eperm-not-echild-on-security_task_wait-failure.patch should be
merged - it is effectively a bug fix.
On the file capabilities support, have any of the filesystem folks
(cc'd) looked at the code yet?
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list
On Thu, 2007-04-19 at 20:54 +, David Wagner wrote:
> Stephen Smalley wrote:
> >Integrity protection requires information flow control; you can't
> >protect a high integrity process from being corrupted by a low integrity
> >process if you don't control the flow of
On Thu, 2007-04-19 at 20:08 +, David Wagner wrote:
> Stephen Smalley wrote:
> >Confinement in its traditional sense (e.g. the 1973 Lampson paper, ACM
> >Vol 16 No 10) means information flow control, which you have agreed
> >AppArmor does not and cannot provide.
>
They aren't truly independent; the composition may lead to surprising
results where each individual program is "confined" exactly as you
specified, but in combination, one is able to corrupt the higher
integrity subject by actions taken by the lower integrity subject.
Particularly in
est in going there (and would have to recant its emphasis on no
application mods to do so). If you actually want to truly confine a
desktop application, you can't limit yourself to the kernel. And the
label model provides a unifying abstraction for dealing with all of
these various objects, wh
at you mean?
I think he means the dependencies on which AppArmor relies, not just its
policy, e.g. since it is name-based, it presumes the filesystem
namespace has been set up by a trusted agent and is correct.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the l
> the
> only way.
You need a way of providing global and persistent security guarantees
for the data, and per-program profiles based on pathname don't get you
there. There is no system view in AA, just a bunch of disconnected
profiles.
--
Stephen Smalley
National Security Agency
-
To un
think that there would be nothing to discuss here.
We could just agree to disagree, and you could just focus on addressing
the issues raised by the vfs folks about how to get your changes into an
acceptable form.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the lin
into an
acceptable form.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
view in AA, just a bunch of disconnected
profiles.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
the filesystem
namespace has been set up by a trusted agent and is correct.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
a
desktop application, you can't limit yourself to the kernel. And the
label model provides a unifying abstraction for dealing with all of
these various objects, whereas the path/natural abstraction model has
no unifying abstraction at all.
--
Stephen Smalley
National Security Agency
directories, where
pathnames are largely useless as an indicator.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2007-04-19 at 20:08 +, David Wagner wrote:
Stephen Smalley wrote:
Confinement in its traditional sense (e.g. the 1973 Lampson paper, ACM
Vol 16 No 10) means information flow control, which you have agreed
AppArmor does not and cannot provide.
Right, that's how I understand
On Thu, 2007-04-19 at 20:54 +, David Wagner wrote:
Stephen Smalley wrote:
Integrity protection requires information flow control; you can't
protect a high integrity process from being corrupted by a low integrity
process if you don't control the flow of information. Plenty of attacks
) be number one (or two or three) CPU user in kernel.
>
> also note that 17.6% of mispredicted branches occurr in security_port_sid.
>
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
4.8875 476 0.6239 311.3766
udp_v4_lookup_longway
if dnsfilter had used epoll, security_port_sid would
probably (?) be number one (or two or three) CPU user in kernel.
also note that 17.6% of mispredicted branches occurr in security_port_sid.
--
Stephen Smalley
eed for lsm
> stacking. I think the idea was that evm would still be able to enforce
> integrity of selinux xattrs without it stack with selinux. So I can see
> where this approach came from.
The enforcement mechanism should be directly integrated into SELinux,
not stacked as a separate mo
be directly integrated into SELinux,
not stacked as a separate module.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2007-02-22 at 13:19 -0800, Andrew Morton wrote:
> > On Thu, 22 Feb 2007 08:22:47 -0500 Stephen Smalley <[EMAIL PROTECTED]>
> > wrote:
> > On Wed, 2007-02-21 at 16:03 -0800, Andrew Morton wrote:
> > >
> > > L
On Thu, 2007-02-22 at 13:19 -0800, Andrew Morton wrote:
On Thu, 22 Feb 2007 08:22:47 -0500 Stephen Smalley [EMAIL PROTECTED]
wrote:
On Wed, 2007-02-21 at 16:03 -0800, Andrew Morton wrote:
Looking at the changes to audit_receive_msg():
if (sid
s (in auditsc.c) appear
to correctly initialize ctx to NULL themselves before calling
selinux_sid_to_string(). But if you'd prefer the function to always
handle it, we can do that.
>
> The coding style in there is a bit odd-looking.
>
> The new __audit_fd_pair() has unneeded brace
in there is a bit odd-looking.
The new __audit_fd_pair() has unneeded braces in it.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
On Mon, 2007-02-19 at 11:01 -0600, Serge E. Hallyn wrote:
> From: Serge E. Hallyn <[EMAIL PROTECTED]>
> Subject: [PATCH -mm] file caps: make on-disk capabilities future-proof
>
> Stephen Smalley has pointed out that the current file capabilities
> will even
On Mon, 2007-02-19 at 11:01 -0600, Serge E. Hallyn wrote:
From: Serge E. Hallyn [EMAIL PROTECTED]
Subject: [PATCH -mm] file caps: make on-disk capabilities future-proof
Stephen Smalley has pointed out that the current file capabilities
will eventually pose a problem.
As the capability set
On Thu, 2007-02-08 at 16:02 -0700, Eric W. Biederman wrote:
> From: Stephen Smalley <[EMAIL PROTECTED]>
>
> Hmmm...turns out to not be quite enough, as the /proc/sys inodes aren't
> truly private to the fs, so we can run into them in a variety of
> security hooks beyond
ot the "/sys" for free as it was part
> of the tree, but it isn't true for clt_table trees.
>
> Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
Acked-by: Stephen Smalley <[EMAIL PROTECTED]>
> ---
> security/selinux/hooks.c |6 ++
> 1 files chang
as it was part
of the tree, but it isn't true for clt_table trees.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
Acked-by: Stephen Smalley [EMAIL PROTECTED]
---
security/selinux/hooks.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/security/selinux/hooks.c b
On Thu, 2007-02-08 at 16:02 -0700, Eric W. Biederman wrote:
From: Stephen Smalley [EMAIL PROTECTED]
Hmmm...turns out to not be quite enough, as the /proc/sys inodes aren't
truly private to the fs, so we can run into them in a variety of
security hooks beyond just the inode hooks
On Thu, 2007-02-08 at 10:53 -0700, Eric W. Biederman wrote:
> Stephen Smalley <[EMAIL PROTECTED]> writes:
>
> >
> > Hmmm...turns out to not be quite enough, as the /proc/sys inodes aren't
> > truly private to the fs, so we can run into them in a variety of
> >
On Wed, 2007-02-07 at 15:21 -0700, Eric W. Biederman wrote:
> Stephen Smalley <[EMAIL PROTECTED]> writes:
>
> > Actually, on further inspection, it looks like the real issue is the
> > "path" name generation; "cat /proc/sys/kernel/modprobe" yields
On Wed, 2007-02-07 at 18:57 -0700, Eric W. Biederman wrote:
> Stephen Smalley <[EMAIL PROTECTED]> writes:
>
> >
> > One related but separate issue is that the /proc/sys inode labeling is
> > also affected by the sysctl patch series. Those inodes used to be
>
801 - 900 of 1023 matches
Mail list logo
