ounts down? Or do you think they made 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-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
duce the need somewhat to
modify some applications that create 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
em
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 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 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 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
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 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
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
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
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:
> > >
> > >
> > >
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
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
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
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 Smalle
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:
> > >
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 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
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 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 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
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 list:
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
if (!strcmp(name, XATTR_NAME_CAPS)) {
> + if (!capable(CAP_SETFCAP))
> + return -EPERM;
> + } else if (!capable(CAP_SYS_ADMIN)) {
> + /* A different attribute in the security
>
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
> put new-model to stage3.
In the discussion of the bsdjail security module back in 2004, Andrew
Morton indicated that acceptance of any new code into mainline requires
that it have a real user base:
http://marc.info/?l=linux-kernel&m=109717928411882&w=2
--
Stephen Smalley
Nationa
On Wed, 2007-07-11 at 10:30 -0700, Casey Schaufler wrote:
> --- Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 2007-07-11 at 08:54 +0900, Kazuki Omo(Company) wrote:
> > > Dear, Sir,
> > >
> > > Sorry for my poorly English. I've just wa
ies to
provide common infrastructure for, but LSM does not). The usual end
result is that only the least common denominator gets used, and no real
improvement is obtained.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe
linux-securit
sk->sk_security = current->security;
+ return 0;
+}
And if the socket outlives the task?
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [EMAIL PROTECTE
On Mon, 2007-07-16 at 07:41 -0700, Casey Schaufler wrote:
> --- Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > On Sat, 2007-07-14 at 14:47 -0700, Casey Schaufler wrote:
> > > The patch exceeds the 40k size rule, coming in at about 100k.
> > > I would be happy
On Mon, 2007-07-16 at 08:32 -0700, Casey Schaufler wrote:
> --- Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 2007-07-16 at 07:41 -0700, Casey Schaufler wrote:
> > > --- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> > >
> > > > On
n't actually write back to the file unless
the mapping is MAP_SHARED. See the selinux hook for comparison.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
M
On Tue, 2007-07-17 at 15:28 -0400, Stephen Smalley wrote:
> On Mon, 2007-07-16 at 21:18 -0700, Casey Schaufler wrote:
> > Thank you for the valuable comments. I have incorporated a good number
> > in the updated patch:
> >
> > http://www.schaufler-ca.com
ode
security blob in d_instantiate after having already set it up once.
You'll eventually have to broach the issue of getting your own
capability bit rather than reusing an existing one.
Obviously those key hooks need to be filled in (or dropped).
--
Stephen Smalley
National Security Agency
led (Operation not permitted).
>
> Boy, that is messed up. The xattrs are attached to the inode, so no way
> should that happen.
Overwriting the existing file won't change the inode.
For suid, this is handled by remove_suid -> notify_change with
ATTR_KILL_SUID/SGID. No equivalent for securi
On Wed, 2007-07-18 at 14:03 -0400, Stephen Smalley wrote:
> On Wed, 2007-07-18 at 12:53 -0500, Serge E. Hallyn wrote:
> > Quoting Andrew Morgan ([EMAIL PROTECTED]):
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA1
> > >
> > > Serge,
> >
d
>rule set is permitted.
> 7. Any other access is denied.
>
> Rules may be explicitly defined by writing subject,object,access
> triples to /smack/load.
>
> Smack rule sets can be easily defined that describe Bell&LaPadula
> sensitivity, Biba integrity, and a
el the ptys
with a label derived from the allocating task at creation time (handled
by d_instantiate hook), and then let userspace relabel them as
appropriate based for the user session label for login/sshd and newrole.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this lis
On Wed, 2007-07-18 at 20:46 -0700, Casey Schaufler wrote:
> --- Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 2007-07-17 at 19:59 -0700, Casey Schaufler wrote:
> > > > > - Speaking of which, are you ok with your MAC model being overridden
> >
On Thu, 2007-07-19 at 08:26 -0700, Casey Schaufler wrote:
> --- Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 2007-07-18 at 18:15 -0700, Casey Schaufler wrote:
> > > --- Joshua Brindle <[EMAIL PROTECTED]> wrote:
>
push the responsibility to the filesystems,
e.g. define some new flags for file_system_type struct that indicate the
right behavior for labeling inodes, and have the security module only
use those flags rather than needing to know about individual filesystem
types.
--
Stephen Smalley
National Securit
ode_change() hook that allows SELinux to set the label according
> to the SELinux policy.
No, labels don't change when an existing file is overwritten; if the
process was allowed to overwrite the file by policy, then the label is
already appropriate. One would prevent untrusted entities f
cted if
> selinux is enabled, but forcing us to use selinux enabled kernels
> (on distro's that may not support selinux) just to test the
> security xattr namespace is a bit of a pain.
You can enable SECURITY_SELINUX in the kernel config but still have it
boot disabled by default via
linux_audit_rule_supplied,
> + .audit_rule_match = selinux_audit_rule_match,
> + .audit_rule_init = selinux_audit_rule_init,
> + .audit_rule_free = selinux_audit_rule_free,
So I'd then expect you to also remove the function prototypes
> is SELinux specific. Any problem with making the security_audit_rule
> interfaces use a void * ? The audit code appears to be accomodating.
The struct is already opaque outside of the security module, so you can
just rename it and implement your own version of the struct in your
module.
--
Stephen Smalley
National Security Agency
-
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
> .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
ine "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 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
On Sun, 2007-08-05 at 17:03 -0700, Casey Schaufler wrote:
> From: Casey Schaufler <[EMAIL PROTECTED]>
>
> This patch interposes LSM interfaces between the audit system
> and SELinux. This helps make SELinux a cleaner LSM and clarifies
> the interfaces provided by the audit system. The audit system
; 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,
> 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-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
->| 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
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-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
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'
changed since
open-time check).
> At least, that's how I interpret the code.
>
>
> If I'm right, and this is incorrect behaviour, then I have most of a patch
> that I'm working on to pass the appropriate credentials around.
--
Stephen Smalley
National Securi
On Fri, 2007-08-31 at 15:32 +0100, David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > That's how mandatory access control is supposed to work; otherwise, a
> > flaw in A can leak the descriptor to B at will in violation of security
> >
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
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-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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-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.
>
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
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.
>
> > >> Probabl
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
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
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;
> s
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
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
; > and refer anyone who's need isn't pretty obvious there.
> > This means that the folks who want to divide CAP_SYSADMIN
> > are going to be disappointed with what they get, but some
> > level of restraint is important.
>
> Sure, I guess my point is, if we ope
> userspace does two getxattrs, one to get the length, then another to get
> the value, selinux will be kmallocing twice.
>
> For a file manager doing a listing on a huge directory and wanting to
> list the selinux type, i could see that being a performance issue. Of
> course th
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
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 */
> +
pen when the protocol implementation implements its own
sendpage operations, of course. So possibly there should be a socket
security hook call in sock_sendpage().
--
Stephen Smalley
National Security Agency
-
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
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]):
> > > > +/*
> > > >
rm(current, current, PROCESS__FORK);
> > }
> >
> > -static int selinux_task_alloc_security(struct task_struct *tsk)
> > +static int selinux_task_alloc_security(struct task_struct *tsk,
> > + struct task_struct *hijack_src)
>
e been unsuccessful in using dentry and vfsmnt from the current
> task_struct via the d_path() lookup function.
audit_log_task_info() is an example.
It isn't a perfect technique, but usually yields the expected answer.
But I wouldn't recommend doing that on every LSM hook call.
--
olling a process
already within the container (hence in theory already limited to its
container), and it continues to execute within that container. What's
the issue there?
> That's where the hijack idea came from. Yes, I called it hijack to make
> sure alarm bells went off :) b
On Tue, 2007-11-27 at 16:38 -0600, Serge E. Hallyn wrote:
> Quoting Stephen Smalley ([EMAIL PROTECTED]):
> > On Tue, 2007-11-27 at 10:11 -0600, Serge E. Hallyn wrote:
> > > Quoting Crispin Cowan ([EMAIL PROTECTED]):
> > > > Just the name "sys_hijack" makes
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);
*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-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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 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 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 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 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 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 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 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 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
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 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
? 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 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: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 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 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
et_sys_snd_skb(struct sk_buff *skb, int family)
> +{
> + return security_ops->inet_sys_snd_skb(skb, family);
> +}
> +EXPORT_SYMBOL(security_inet_sys_snd_skb);
> +
> void security_sock_graft(struct sock *sk, struct socket *parent)
> {
> security_ops->sock_graft(sk, parent);
>
>
> --
> 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-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2007-12-14 at 16:50 -0500, Paul Moore wrote:
> Add a secctx_to_secid() LSM hook to go along with the existing
> secid_to_secctx() LSM hook. This patch also includes the SELinux
> implementation for this hook.
Acked-by: Stephen Smalley <[EMAIL PROTECTED]>
This one can go
t; \
> + if ((_d)->type == AVC_AUDIT_DATA_NET) \
> + (_d)->u.net.netif = -1; }
As a minor nit, at the same time you do this, turn this into a static
inline function please.
>
> /*
> * AVC statistics
>
>
> --
> 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-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
d)
> +{
> + struct sel_netnode *node;
> +
> + rcu_read_lock();
> + node = sel_netnode_find(addr, family);
> + if (node != NULL) {
> + *sid = node->nsec.sid;
> + rcu_read_unlock();
> + return 0;
> + }
> + rcu_read_unlock();
> +
> + return sel_netnode_sid_slow(addr, family, sid);
> +}
> +
> +/**
> + * sel_netnode_flush - Flush the entire network address table
> + *
> + * Description:
> + * Remove all entries from the network address table.
> + *
> + */
> +static void sel_netnode_flush(void)
> +{
> + u32 idx;
> + struct sel_netnode *node;
> +
> + spin_lock_bh(&sel_netnode_lock);
> + for (idx = 0; idx < SEL_NETNODE_HASH_SIZE; idx++)
> + list_for_each_entry(node, &sel_netnode_hash[idx], list)
> + sel_netnode_destroy(node);
> + spin_unlock_bh(&sel_netnode_lock);
> +}
> +
> +static int sel_netnode_avc_callback(u32 event, u32 ssid, u32 tsid,
> + u16 class, u32 perms, u32 *retained)
> +{
> + if (event == AVC_CALLBACK_RESET) {
> + sel_netnode_flush();
> + synchronize_net();
> + }
> + return 0;
> +}
> +
> +static __init int sel_netnode_init(void)
> +{
> + int iter;
> + int ret;
> +
> + if (!selinux_enabled)
> + return 0;
> +
> + for (iter = 0; iter < SEL_NETNODE_HASH_SIZE; iter++)
> + INIT_LIST_HEAD(&sel_netnode_hash[iter]);
> +
> + ret = avc_add_callback(sel_netnode_avc_callback, AVC_CALLBACK_RESET,
> +SECSID_NULL, SECSID_NULL, SECCLASS_NULL, 0);
> + if (ret != 0)
> + panic("avc_add_callback() failed, error %d\n", ret);
> +
> + return ret;
> +}
> +
> +__initcall(sel_netnode_init);
>
>
> --
> 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-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
7;m thinking we should split the permissions
> like this:
>
> allow netif_t peer_t:peer if_egress;
> allow netnode_t peer_t: peer node_egress;
>
> ... and do something similar for the ingress side. Thoughts?
That starts to sound a lot like using netif and node classes instead of
the peer class.
allow peer_t netif_t:netif egress;
allow peer_t netnode_t:node egress;
>
> > + }
> > +
> > + return err;
> > +}
>
--
Stephen Smalley
National Security Agency
-
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
1 - 100 of 173 matches
Mail list logo
