On 05/03/2013 10:07 AM, Waiman Long wrote:
On 04/10/2013 02:26 PM, Waiman Long wrote:
While running the high_systime workload of the AIM7 benchmark on
a 2-socket 12-core Westmere x86-64 machine running 3.8.2 kernel,
it was found that a pretty sizable amount of time was spent in the
SELinux code.
On 03/15/2013 11:24 AM, Thomas COUDRAY wrote:
2013/3/15 Stephen Smalley :
f is truly a regular file and not a symlink pointing to a regular file?
f is a truly regular file.
before_t and after_t are both defined in the policy?
Only before_t was defined in the policy.
If not defined in
On 03/15/2013 06:54 AM, Thomas COUDRAY wrote:
Hi,
I encounter trouble that I can't explain when labelling my files.
Here are steps to reproduce (on both 3.2.37 and 3.7.3, with selinux, on
an ext4 fs):
0 - have a regular file "f", with a "before_t" security.selinux attribute
1 - reboot with selinu
On 02/06/2013 10:21 AM, Tommi Rantala wrote:
2013/2/6 Stephen Smalley :
On 02/06/2013 07:56 AM, Tommi Rantala wrote:
Hello,
I'm hitting an oops in selinux_msg_queue_msgrcv() when fuzzing with
Trinity as the root user (in a qemu VM):
NULL msg->security at that point is a bug in
On 02/06/2013 07:56 AM, Tommi Rantala wrote:
Hello,
I'm hitting an oops in selinux_msg_queue_msgrcv() when fuzzing with
Trinity as the root user (in a qemu VM):
NULL msg->security at that point is a bug in the ipc subsystem; SELinux
is just the messenger. Normally msg->security is set for ev
On 01/07/2013 08:54 PM, Casey Schaufler wrote:
Subject: [PATCH v12 0/9] LSM: Multiple concurrent LSMs
Change the infrastructure for Linux Security Modules (LSM)s
from a single vector of hook handlers to a list based method
for handling multiple concurrent modules.
A level of indirection has bee
On 01/02/2013 11:37 AM, Casey Schaufler wrote:
On 1/2/2013 7:35 AM, Dave Jones wrote:
Along the same lines as 779302e67835fe9a6b74327e54969ba59cb3478a, xattrs
can cause big allocations, which are likely to fail under memory pressure..
Adding LSM and SELinux lists.
[20539.081122] trinity-chil
r
security=capability.
Having to specify selinux=0 smack=0 foo=0 just to get bar wouldn't be
pretty. Not that anyone would want to do that, of course...
--
Stephen Smalley
National Security Agency
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
2008-02-15
> 16:59:09.0 +0300
> +++ 25/drivers/usb/core/inode.c 2008-02-25 19:21:09.0 +0300
> @@ -728,7 +728,8 @@ static void usbfs_remove_device(struct u
> sinfo.si_errno = EPIPE;
> sinfo.si_code = SI_ASYNC
093,6 +1120,11 @@ static int smack_task_movememory(struct
> static int smack_task_kill(struct task_struct *p, struct siginfo *info,
> int sig, u32 secid)
> {
> + int rc;
> +
> + rc = cap_task_kill(p, info, sig, secid);
> + if (rc != 0
roc/root.c
> +++ b/fs/proc/root.c
> @@ -129,6 +129,7 @@ void __init proc_root_init(void)
> proc_root_fs = proc_mkdir("fs", NULL);
> proc_root_driver = proc_mkdir("driver", NULL);
> proc_mkdir("fs/nfsd", NULL); /* somewhere for the nfsd
outlive the task it points
> back to.
>
> It seems that the backpointer can be dispensed with. Nothing particularly
> seems to use it. Do you know the reason for its existence?
Looks unused now.
Similarly for some of the other security structs.
Only inode, superblock, and sock bac
APABILITIES is not set
> # CONFIG_SECURITY_ROOTPLUG is not set
> -# CONFIG_SECURITY_SMACK is not set
> +CONFIG_SECURITY_SMACK=y
> CONFIG_XOR_BLOCKS=m
> CONFIG_ASYNC_CORE=m
> CONFIG_ASYNC_MEMCPY=m
> @@ -2396,7 +2410,9 @@ CONFIG_CRYPTO_AUTHENC=y
> # CONFIG_CRYPTO_HW is not set
>
#x27;s file_has_perm() is doing spin_lock() on an
> uninitialised (or already locked) spinlock.
The trace looks bogus to me - I don't see how file_has_perm() could have
been called there, and file_has_perm() doesn't directly take any spin
locks.
--
Stephen Smalley
National Security Agency
--
the type has not changed.
>
> Potential users of this support include pam_namespace.so (directory
> polyinstantiation) and the SELinux X support (property polyinstantiation).
>
> Signed-off-by: Eamon Walsh <[EMAIL PROTECTED]>
Acked-by: Stephen Smalley <[EMAIL P
sufficiently big. This is included in the returned count. If no LSM is
> in force then an empty string will be returned.
>
> A process must have view permission on the key for this function to be
> successful.
>
> Signed-off-by: David Howells <[EMAIL
On Tue, 2008-01-15 at 10:10 -0800, Casey Schaufler wrote:
> --- David Howells <[EMAIL PROTECTED]> wrote:
>
> > Stephen Smalley <[EMAIL PROTECTED]> wrote:
> >
> > > > (3) Check that the kernel may create files as a particular secid (this
> > >
On Tue, 2008-01-15 at 16:03 +, David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > > (3) Check that the kernel may create files as a particular secid (this
> > > could be specified indirectly by specifying an inode, which would
> &
NULL);
>
> Rather than specifically dedicating them to the cache, I made them general.
Make sure that you or Dan submits a policy patch to register these
classes and permissions in the policy when the kernel patch is queued
for merge.
--
Stephen Smalley
National Security Agenc
On Mon, 2008-01-14 at 14:01 +, David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > > avc_has_perm(daemon_tsec->sid, nominated_sid,
> > >SECCLASS_CACHE, CACHE__USE_AS_OVERRIDE, NULL);
> > >
> > > And I
On Wed, 2008-01-09 at 18:56 +, David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > Right, the latter is reasonable.
> > Requires adding the class and permission definition to
> > policy/flask/security_classes and policy/flask/access_vectors
s and permission definition to
policy/flask/security_classes and policy/flask/access_vectors and then
regenerating the kernel headers from those files, ala:
svn co http://oss.tresys.com/repos/refpolicy/trunk refpolicy
cd refpolicy/policy/flask
vi security_classes access_vectors
make
m
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
> >> fo
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.
>
> C
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 good id
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.
> >
s the
> > 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 fr
? 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 not
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 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 users
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
> > returned by a
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:
> > >
> > > > Otherw
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
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
*inode)
> +{
> + struct task_security_struct *tsec = sec->security;
> + struct inode_security_struct *isec = inode->i_security;
> +
> + tsec->create_sid = isec->sid;
> + return 0;
> +}
> +
> static int selinux_task_setuid(uid_t id0, uid_t id1, uid_t id2, int flags)
> {
> /* Since setuid only affects the current process, and
> @@ -4884,6 +4927,8 @@ static struct security_operations selinux_ops = {
> .task_alloc_security = selinux_task_alloc_security,
> .task_free_security = selinux_task_free_security,
> .task_dup_security =selinux_task_dup_security,
> + .task_kernel_act_as = selinux_task_kernel_act_as,
> + .task_create_files_as = selinux_task_create_files_as,
> .task_setuid = selinux_task_setuid,
> .task_post_setuid = selinux_task_post_setuid,
> .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
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/
security/security.c b/security/security.c
> > index 0e1f1f1..16213e3 100644
> > --- 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);
&
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]):
> > > > +/*
> > > >
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
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
&
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
-
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/
and booting a new kernel shouldn'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, b
illing a
process with more capabilities, 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 */
> +
se
> + strncpy(smack, smack_net_ambient, SMK_MAXLEN);
> + netlbl_secattr_destroy(&secattr);
> + /*
> + * Receiving a packet requires that the other end
> + * be able to write here. Read access is not required.
> + * This is the simplist poss
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
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,
> an
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;
>
ermission system.
A LSM implements 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 Sm
ux
> > 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]>
> > ---
> >
to do it.
Note that Serge said "SELinux re-written on top of 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 shou
esent in the system, and gives
you the option of controlling it. Your choice as to at what granularity
to apply it.
> SELinux is designed to increase in complexity as it evolves. Making
> it simpler would conflict with the design goal of finer granularity.
>
> > >> Probably
ense to merge no security 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 emula
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.
>
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
rity_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/
I changed some kernel configs.
>
> 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
m_r:kernel_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&m=118271540932264&w=2
--
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
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
ial shouldn'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
-
daemon into a process label that the kernel, and only the kernel, 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'
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 [EMAI
->| AUDIT |
> ++ +---+
>
> 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 - w
> for example, for SELinux, the security ID with which this task acts on
> things, and the security 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/
; For
> > the most part, this is entirely sufficient, but in the cache driver case,
> > 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,
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 au
> .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
to userspace. These days, initial policy 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/
nux policy.
>
> (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/
s was by open file 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 t
if (!strcmp(name, XATTR_NAME_CAPS)) {
> + if (!capable(CAP_SETFCAP))
> + return -EPERM;
> + } else if (!capable(CAP_SYS_ADMIN)) {
> + /* A different attribute in the security
>
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
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
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&qu
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&#x
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
with respect to direct file access
> 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
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:
> > >
aused by malicious 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 Small
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
ct my Mozilla to not 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 di
certification 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 th
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:
> > >
> > >
> > >
s)
although we 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 l
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
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
t; Kentaro Takeda (version 2.0 author)
> 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/Celf
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 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 a
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
AVC to
perform the checks, calling 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 t
0x0040UL
> #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
&
401 - 500 of 584 matches
Mail list logo
