On Tue, 2007-12-18 at 19:28 -0800, Crispin Cowan wrote:
Stephen Smalley wrote:
It is if I have to maintain a special pieces of code for each possible LSM.
One piece for SELinux, one piece for AppArmour, one piece for Smack, one
piece
for Casey's security system. That sounds like a pain
On Thu, 2007-12-13 at 17:01 +, David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > They would correspond with the operations provided by the /dev/cachefiles
> > interface, at the granularity you want to support distinctions to be made.
>
On Thu, 2007-12-13 at 15:36 +, David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > It is just a way of carving up the permission space, typically based on
> > object type, but it can essentially be arbitrary. The check in this
> > case seem
On Wed, 2007-12-12 at 22:55 +, David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > More likely, run it at build time in your .spec file to generate
> > cachefiles.conf,
>
> I don't think sticking it in cachefiles.conf is a goo
On Wed, 2007-12-12 at 22:49 +, David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > > Have you example code for the security hook you mention? I'm not sure I
> > > understand why security_secctx_to_secid() is not sufficient.
> >
>
On Wed, 2007-12-12 at 22:49 +, David Howells wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
Have you example code for the security hook you mention? I'm not sure I
understand why security_secctx_to_secid() is not sufficient.
security_secctx_to_secid() would just validate
On Wed, 2007-12-12 at 22:55 +, David Howells wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
More likely, run it at build time in your .spec file to generate
cachefiles.conf,
I don't think sticking it in cachefiles.conf is a good idea necessarily.
That has to be an administrator
On Thu, 2007-12-13 at 15:36 +, David Howells wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
It is just a way of carving up the permission space, typically based on
object type, but it can essentially be arbitrary. The check in this
case seems specific to cachefiles since
On Thu, 2007-12-13 at 17:01 +, David Howells wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
They would correspond with the operations provided by the /dev/cachefiles
interface, at the granularity you want to support distinctions to be made.
Can this be made simpler by the fact
> > particular cache context that a particular instance of a running daemon is
> > using.
>
> Yes, but forgive me being slow, I don't see the problem.
>
>
> Casey Schaufler
> [EMAIL PROTECTED]
--
Stephen Smalley
National Security Agency
--
To unsubscribe from this lis
run? Spat out to
> > where?
>
> Put it in /etc/init.d/cachefiles and run it at boot time. Put the
> result into /etc/cachefiles.conf. Have cachefilesd read it and pass
> it downward.
More likely, run it at build time in your .spec file to generate
cachefiles.conf, then run it again
On Wed, 2007-12-12 at 18:29 +, David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > That sounds workable, although I think he will want a more specific hook
> > than security_secctx_to_secid(), or possibly a second hook call, that
> > would
On Wed, 2007-12-12 at 08:51 -0800, Casey Schaufler wrote:
> --- Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 2007-12-11 at 15:04 -0800, Casey Schaufler wrote:
> > > --- David Howells <[EMAIL PROTECTED]> wrote:
> > >
> &g
On Tue, 2007-12-11 at 15:04 -0800, Casey Schaufler wrote:
> --- David Howells <[EMAIL PROTECTED]> wrote:
>
> > Stephen Smalley <[EMAIL PROTECTED]> wrote:
> >
> > > All your code has to do is invoke a function provided by libselinux.
> >
>
On Tue, 2007-12-11 at 15:04 -0800, Casey Schaufler wrote:
--- David Howells [EMAIL PROTECTED] wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
All your code has to do is invoke a function provided by libselinux.
Calling libselinux means it's a special case for a specific LSM.
I
On Wed, 2007-12-12 at 08:51 -0800, Casey Schaufler wrote:
--- Stephen Smalley [EMAIL PROTECTED] wrote:
On Tue, 2007-12-11 at 15:04 -0800, Casey Schaufler wrote:
--- David Howells [EMAIL PROTECTED] wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
All your code has to do
On Wed, 2007-12-12 at 18:29 +, David Howells wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
That sounds workable, although I think he will want a more specific hook
than security_secctx_to_secid(), or possibly a second hook call, that
would not only validate the context but authorize
]
--
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/
/cachefiles.conf. Have cachefilesd read it and pass
it downward.
More likely, run it at build time in your .spec file to generate
cachefiles.conf, then run it again maybe upon a policy update or if the
user selects a different policy.
--
Stephen Smalley
National Security Agency
--
To unsubscribe from
On Tue, 2007-12-11 at 20:42 +, David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > > That sounds too SELinux specific. How do I do it so that it works for any
> > > LSM?
> >
> > You can't. There is no LSM for userspace;
On Tue, 2007-12-11 at 11:26 -0800, Casey Schaufler wrote:
> --- Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 2007-12-10 at 14:26 -0800, Casey Schaufler wrote:
> > > --- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> > >
> > > >
On Mon, 2007-12-10 at 15:46 -0800, Casey Schaufler wrote:
> --- David Howells <[EMAIL PROTECTED]> wrote:
>
> > Stephen Smalley <[EMAIL PROTECTED]> wrote:
> >
> > > From a config file whose pathname would be provided by libselinux (ala
> > > the w
On Mon, 2007-12-10 at 23:36 +, David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > From a config file whose pathname would be provided by libselinux (ala
> > the way in which dbusd imports contexts), or directly as a context
> > ret
On Mon, 2007-12-10 at 14:26 -0800, Casey Schaufler wrote:
> --- Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 2007-12-10 at 21:08 +, David Howells wrote:
> > > Stephen Smalley <[EMAIL PROTECTED]> wrote:
> > >
> > > >
On Mon, 2007-12-10 at 14:26 -0800, Casey Schaufler wrote:
--- Stephen Smalley [EMAIL PROTECTED] wrote:
On Mon, 2007-12-10 at 21:08 +, David Howells wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
Otherwise, only other issue I have with this interface is it won't
generalize
On Mon, 2007-12-10 at 23:36 +, David Howells wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
From a config file whose pathname would be provided by libselinux (ala
the way in which dbusd imports contexts), or directly as a context
returned by a libselinux function.
That sounds too
On Mon, 2007-12-10 at 15:46 -0800, Casey Schaufler wrote:
--- David Howells [EMAIL PROTECTED] wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
From a config file whose pathname would be provided by libselinux (ala
the way in which dbusd imports contexts), or directly as a context
On Tue, 2007-12-11 at 11:26 -0800, Casey Schaufler wrote:
--- Stephen Smalley [EMAIL PROTECTED] wrote:
On Mon, 2007-12-10 at 14:26 -0800, Casey Schaufler wrote:
--- Stephen Smalley [EMAIL PROTECTED] wrote:
On Mon, 2007-12-10 at 21:08 +, David Howells wrote:
Stephen Smalley
On Tue, 2007-12-11 at 20:42 +, David Howells wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
That sounds too SELinux specific. How do I do it so that it works for any
LSM?
You can't. There is no LSM for userspace; LSM specifically disavowed
any common userspace API
On Mon, 2007-12-10 at 21:08 +, David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > Otherwise, only other issue I have with this interface is it won't
> > generalize to dealing with nfsd, where we want to set the acting context
> > to a conte
On Mon, 2007-12-10 at 17:07 +, David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > > + tsec->create_sid = SECINITSID_UNLABELED;
> > > + tsec->keycreate_sid = SECINITSID_UNLABELED;
> > > + tsec->sockcreate_sid = SECINITSID_U
le creation context in a security record to the same as the
> + * objective context of the specified inode
> + */
> +static int selinux_task_create_files_as(struct task_security *sec,
> + struct inode *inode)
> +{
> + struct task_security_st
,
.task_setgid = selinux_task_setgid,
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to [EMAIL PROTECTED] with
the words unsubscribe selinux without quotes as the message.
--
Stephen Smalley
On Mon, 2007-12-10 at 17:07 +, David Howells wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
+ tsec-create_sid = SECINITSID_UNLABELED;
+ tsec-keycreate_sid = SECINITSID_UNLABELED;
+ tsec-sockcreate_sid = SECINITSID_UNLABELED;
Cleared means what? Setting to 0? Or is there some
On Mon, 2007-12-10 at 21:08 +, David Howells wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
Otherwise, only other issue I have with this interface is it won't
generalize to dealing with nfsd, where we want to set the acting context
to a context we obtain from or determine based upon
> > --- a/security/security.c
> > +++ b/security/security.c
> > @@ -1079,4 +1079,9 @@ int security_key_permission(key_ref_t key_ref,
> > return security_ops->key_permission(key_ref, context, perm);
> > }
> >
> > +int security_key_getsecurity(struct key
of the selinux mailing list.
If you no longer wish to subscribe, send mail to [EMAIL PROTECTED] with
the words unsubscribe selinux without quotes as the message.
--
Stephen Smalley
National Security Agency
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
On Wed, 2007-11-21 at 09:21 -0800, Casey Schaufler wrote:
> --- Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 2007-11-21 at 09:48 -0600, Serge E. Hallyn wrote:
> > > Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
> > > > +/*
> > > >
ith
security-module-specific capabilities? CAP_MAC_OVERRIDE is specific to
Smack - other MAC modules like SELinux won't honor it. Maybe it should
be CAP_SMACK_OVERRIDE.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&q
On Tue, 2007-11-20 at 15:17 +, Christoph Hellwig wrote:
> On Tue, Nov 20, 2007 at 10:05:05AM -0500, Stephen Smalley wrote:
> > > Nice, getting rid of this is a very good step formwards. Unfortunately
> > > we have another copy of this junk in
&
On Tue, 2007-11-20 at 15:17 +, Christoph Hellwig wrote:
On Tue, Nov 20, 2007 at 10:05:05AM -0500, Stephen Smalley wrote:
Nice, getting rid of this is a very good step formwards. Unfortunately
we have another copy of this junk in
security/selinux/selinuxfs.c:sel_remove_entries
- other MAC modules like SELinux won't honor it. Maybe it should
be CAP_SMACK_OVERRIDE.
--
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 Wed, 2007-11-21 at 09:21 -0800, Casey Schaufler wrote:
--- Stephen Smalley [EMAIL PROTECTED] wrote:
On Wed, 2007-11-21 at 09:48 -0600, Serge E. Hallyn wrote:
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
+/*
+ * There are not enough CAP bits available to make this
+ * real
On Tue, 2007-11-20 at 15:17 +, Christoph Hellwig wrote:
> On Tue, Nov 20, 2007 at 10:05:05AM -0500, Stephen Smalley wrote:
> > > Nice, getting rid of this is a very good step formwards. Unfortunately
> > > we have another copy of this junk in
&
the only real problem here the clearing of f_op? If so, we can
likely remove that from sel_remove_entries() without harm, and fix the
checks for it to use something more reliable.
--
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/
obsolete entries from the prior policy when we load a new policy.
Is the only real problem here the clearing of f_op? If so, we can
likely remove that from sel_remove_entries() without harm, and fix the
checks for it to use something more reliable.
--
Stephen Smalley
National Security Agency
On Tue, 2007-11-20 at 15:17 +, Christoph Hellwig wrote:
On Tue, Nov 20, 2007 at 10:05:05AM -0500, Stephen Smalley wrote:
Nice, getting rid of this is a very good step formwards. Unfortunately
we have another copy of this junk in
security/selinux/selinuxfs.c:sel_remove_entries
dn't
trigger it.
Even when triggered, a relabel shouldn't call setxattr on the file
unless its existing on-disk label doesn't match the file contexts
specification in policy. There is a force option that unconditionally
sets the label on all files, but I don't see that being used by the
autorelabel
, a relabel shouldn't call setxattr on the file
unless its existing on-disk label doesn't match the file contexts
specification in policy. There is a force option that unconditionally
sets the label on all files, but I don't see that being used by the
autorelabel support.
--
Stephen Smalley
even if they have the same uid, so that
when you have a program marked with file capabilities instead of a
setuid-0 program, that program can't be sent arbitrary signals by the
caller.
> +
> + /* sigcont is permitted within same session */
> + if (sig == SIGCONT && (task_sessi
is permitted within same session */
+ if (sig == SIGCONT (task_session_nr(current)==task_session_nr(p)))
+ return 0;
+
if (secid)
/*
* Signal sent as a particular user.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from
gt; + netlbl_secattr_destroy();
> + /*
> + * Receiving a packet requires that the other end
> + * be able to write here. Read access is not required.
> + * This is the simplist possible security model
> + * for networking.
> + */
> +
EC, NULL);
> if (error)
> return error;
> @@ -1509,6 +1513,8 @@ static inline int may_create(struct inod
> return -EEXIST;
> if (IS_DEADDIR(dir))
> return -ENOENT;
> + if (nd)
> + nd->flags |= LOOKUP_CONTIN
return -EEXIST;
if (IS_DEADDIR(dir))
return -ENOENT;
+ if (nd)
+ nd-flags |= LOOKUP_CONTINUE;
return permission(dir,MAY_WRITE | MAY_EXEC, nd);
}
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send
== 0)
+ strcpy(ssp-smk_packet, smack);
+ ssp-smk_depth++;
Ditto.
+
+ return 0;
+}
+
--
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
On Wed, 2007-10-24 at 20:46 -0700, Casey Schaufler wrote:
> From: Casey Schaufler <[EMAIL PROTECTED]>
>
> Smack is the Simplified Mandatory Access Control Kernel.
>
> Smack implements mandatory access control (MAC) using labels
> attached to tasks and data containers, including files, SVIPC,
>
On Wed, 2007-10-24 at 20:46 -0700, Casey Schaufler wrote:
From: Casey Schaufler [EMAIL PROTECTED]
Smack is the Simplified Mandatory Access Control Kernel.
Smack implements mandatory access control (MAC) using labels
attached to tasks and data containers, including files, SVIPC,
and other
return 0;
> default:
> return -EINVAL;
> @@ -220,7 +241,7 @@ static int get_file_caps(struct linux_binprm *bprm)
> {
> struct dentry *dentry;
> int rc = 0;
> - struct vfs_cap_data incaps;
> + union vfs_cap_union incaps;
>
)
rc = inode-i_op-getxattr(dentry, XATTR_NAME_CAPS,
incaps, XATTR_CAPS_SZ);
else
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
lements a security model, where that model may encompass all
processes and objects. SELinux (and Smack) in particular implement
mandatory access control and thus need to enforce consistent policy over
all processes and objects based on their security labels.
--
Stephen Smalley
National Security Agency
ELinux
> > would not always show up, but would be easy and intuitive to find.
> >
> > Signed-off-by: Eric Paris <[EMAIL PROTECTED]>
> > Acked-by: Stephen Smalley <[EMAIL PROTECTED]>
> > Signed-off-by: James Morris <[EMAIL PROTECTED]>
> > ---
> >
.
Signed-off-by: Eric Paris [EMAIL PROTECTED]
Acked-by: Stephen Smalley [EMAIL PROTECTED]
Signed-off-by: James Morris [EMAIL PROTECTED]
---
security/selinux/Kconfig |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/security/selinux/Kconfig b/security
on their security labels.
--
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/
f Smack", not "rewrite
Smack to be more like SELinux". I don't believe the former is even
possible, given that Smack is strictly less expressive and granular by
design. Rewriting Smack to be more like SELinux should be possible, but
seems like more work than emulating Smack on SELin
to be more like SELinux. I don't believe the former is even
possible, given that Smack is strictly less expressive and granular by
design. Rewriting Smack to be more like SELinux should be possible, but
seems like more work than emulating Smack on SELinux via policy, and to
what end?
--
Stephen
to increase in complexity as it evolves. Making
> it simpler would conflict with the design goal of finer granularity.
>
> > >> Probably a fair amount of that just means better tools.
>
> Now what kind of tools are you talking about? Static analysis?
> Data flow dia
for userland so that you don't need separate
versions of ls, ps, sshd, etc for Smack vs SELinux vs. whatever.
--
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
modules at all than to
have LSM and many different security modules.
If Smack is mergeable despite likely being nothing more than a strict
subset of SELinux (MAC, label-based, should be easily emulated on top of
SELinux or via fairly simple extension to it to make such emulation
simpler or more opti
than a strict
subset of SELinux (MAC, label-based, should be easily emulated on top of
SELinux or via fairly simple extension to it to make such emulation
simpler or more optimal), then what isn't mergeable as a separate
security module?
--
Stephen Smalley
National Security Agency
On Wed, 2007-09-26 at 14:30 +0100, David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > Precisely when to use one identity vs. the other though isn't always
> > clear, and the potential for accidental divergence is also a concern.
>
On Wed, 2007-09-26 at 14:30 +0100, David Howells wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
Precisely when to use one identity vs. the other though isn't always
clear, and the potential for accidental divergence is also a concern.
What should auditing use in audit_filter_rules
changed since the open-time check. A new LSM
> hook, security_dentry_open, is added to capture the necessary state at
> open time to allow this optimization.
>
> Signed-off-by: Yuichi Nakamura<[EMAIL PROTECTED]>
Thanks, looks good.
Acked-by: Stephen Smalley <[EMAIL
labels have
changed or the policy has changed since the open-time check. A new LSM
hook, security_dentry_open, is added to capture the necessary state at
open time to allow this optimization.
Signed-off-by: Yuichi Nakamura[EMAIL PROTECTED]
Thanks, looks good.
Acked-by: Stephen Smalley [EMAIL
On Wed, 2007-09-12 at 17:51 +0900, Yuichi Nakamura wrote:
> Hi.
>
> Stephen Smalley pointed out possibility of race condition
> in off-list discussion.
> Stephen Smalley said:
> > One other observation about the patch: it presently leaves open a
> > (small) race win
On Wed, 2007-09-12 at 17:51 +0900, Yuichi Nakamura wrote:
Hi.
Stephen Smalley pointed out possibility of race condition
in off-list discussion.
Stephen Smalley said:
One other observation about the patch: it presently leaves open a
(small) race window in which the file could get
_file_receive
> return security_ops->file_receive (file);
> }
>
> +static inline int security_dentry_open (struct file *file, int flags)
> +{
> + return security_ops->dentry_open (file, flags);
> +}
> +
> static inline int security_task_create (unsigned long clone_flags)
> {
> return security_ops->task_create (clone_flags);
> @@ -2529,6 +2540,11 @@ static inline int security_file_receive
> return 0;
> }
>
> +static inline int security_dentry_open (struct file *file, int flags)
> +{
> + return 0;
> +}
> +
> static inline int security_task_create (unsigned long clone_flags)
> {
> return 0;
>
> Regards,
--
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/
(unsigned long clone_flags)
{
return 0;
Regards,
--
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
nfigs.
>
> Overhead more than 100%
> I also found about 70-90% overhead in ARM.
>
> 2. About patch
> I found a overhead in selinux_file_permission function.
> This is a function that is called in read/write calls,
> and does SELinux permission check.
> SELinux checks
a overhead in selinux_file_permission function.
This is a function that is called in read/write calls,
and does SELinux permission check.
SELinux checks permission both in open and read/write time.
Stephen Smalley sugessted that we can usually skip permission check
in selinux_file_permission
_t:s0 tclass=packet
>
> so the roots of the problem may lie between 2.6.20.4 and 2.6.20.6
>
> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console2.log
Might be related to this:
http://marc.info/?l=git-commits-head=118271540932264=2
--
Stephen Smalley
On Wed, 2007-08-22 at 16:29 +0200, Michal Piotrowski wrote:
> On 22/08/07, James Morris <[EMAIL PROTECTED]> wrote:
> > On Wed, 22 Aug 2007, Stephen Smalley wrote:
> >
> > > Oops, never mind - tail still follows secmark, so that shouldn't matter.
> > > So I'm
On Wed, 2007-08-22 at 09:36 -0400, Stephen Smalley wrote:
> On Wed, 2007-08-22 at 06:23 -0700, James Morris wrote:
> > On Wed, 22 Aug 2007, Michal Piotrowski wrote:
> >
> > > I got a problem with SELinux
> > > http://www.stardust.webpages.pl/files/tbf/bitis-g
houldn't be against kernel_t unless he has iptables
SECMARK rules that assign that value.
It's the change to the skb allocator - no longer clears up through
truesize and thus secmark is garbage initially. That would apply to
mainline too.
--
Stephen Smalley
National Security Agency
-
To unsubscribe
rules that assign that value.
It's the change to the skb allocator - no longer clears up through
truesize and thus secmark is garbage initially. That would apply to
mainline too.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Wed, 2007-08-22 at 09:36 -0400, Stephen Smalley wrote:
On Wed, 2007-08-22 at 06:23 -0700, James Morris wrote:
On Wed, 22 Aug 2007, Michal Piotrowski wrote:
I got a problem with SELinux
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console.log
http
On Wed, 2007-08-22 at 16:29 +0200, Michal Piotrowski wrote:
On 22/08/07, James Morris [EMAIL PROTECTED] wrote:
On Wed, 22 Aug 2007, Stephen Smalley wrote:
Oops, never mind - tail still follows secmark, so that shouldn't matter.
So I'm not sure why we are getting a bad value for secmark
://marc.info/?l=git-commits-headm=118271540932264w=2
--
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
can use.
> >
> > The kernel's label gives it, amongst other things, the additional rights to
> > do
> > mkdir, creat, open, read, write, setxattr, getxattr, rename - things the
> > daemon isn't allowed to do.
>
> With Smack you can leave the label alone, rais
tly
> set the file label using the xattr interfaces.
xattr interfaces don't help with the initial labeling of the file when
it is created.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PRO
when
it is created.
--
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/
there). So even that would
have to be encapsulated within a hook.
--
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
++ +---+
>
> For Stephen and NFS, he could then generate a context from NFS which nfsd
> could then put in place. Perhaps any unfilled slot would be ignored by the
> LSM module to which it belonged.
Seems like over-design - we don't need to support LSM st
ecurity ID with which this task creates files.
I don't see how that helps with nfsd assuming the label of a remote
client process.
>
> (2) int security_act_as_self(void);
>
> Restore the context as which we're asking.
>
> This would mean that the task's security context would have to be able to
> store
> acting security IDs for everything, but I don't think that's too much of a
> stretch resourcewise.
--
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/
gt; > it's
> > a problem.
>
> The cache driver is a unique case with an unusual function. It's pretty
> obvious that the kernel architecture, the VFS architecture, LSM, SELinux,
> NFS and pretty much everyone else has given no thought whatever to the
> implications of their d
does today
with the fsuid/fsguid, just applied to the security label.
--
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
that the task's security context would have to be able to
store
acting security IDs for everything, but I don't think that's too much of a
stretch resourcewise.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
level of context.
What was the objection again to the original interface, aside from
replacing u32 secids with void* security blobs?
--
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
ll be created in the
> > cache.
>
> This is SELinux specific functionality. It should not be an LSM
> interface.
Odd, you proposed exactly the same hook (aside from naming convention
and secid as argument vs. as retval) in recent postings on linux-audit
and selinux list for use by the audit s
specific functionality. It should not be an LSM
interface.
Odd, you proposed exactly the same hook (aside from naming convention
and secid as argument vs. as retval) in recent postings on linux-audit
and selinux list for use by the audit system.
--
Stephen Smalley
National Security Agency
> .inode_removexattr =cap_inode_removexattr,
> + .inode_removexattr =cap_inode_killpriv,
s/inode_removexattr/inode_killpriv/
Also, doesn't SELinux then need to define a corresponding hook function
to call the secondary module? Otherwise, it will fall back to the d
701 - 800 of 1023 matches
Mail list logo
