hile this code could be put into a library if desired, there is no need
to make any changes for filesystems with text options (i.e. the general
case).
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the
68
> +#define SECCLASS_KERNEL_SERVICE 69
I just pushed a patch to Linus from Stephen which uses this class number;
you'll likely need to bump it to 70.
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscri
;sockcreate_sid = tsec1->sockcreate_sid;
> + tsec2->ptrace_sid = SECINITSID_UNLABELED;
> + sec->security = tsec2;
> +
> + return 0;
> }
Why manually copy these fields after a kmemdup?
What about the task backpointer? (i.e. tsec2->task)
--
James Morris
in entry.S via asm
> offsets.
>
> Sparc needs further alteration as it refers to UID & GID in sclow.S via asm
> offsets.
>
> Signed-off-by: David Howells <[EMAIL PROTECTED]>
Reviewed-by: James Morris <[EMAIL PROTECTED]>
(SELinux stuff mostly).
--
James Morris
<
On Fri, 8 Feb 2008, David Howells wrote:
> Change current->fs[ug]id to current_fs[ug]id() so that fsgid and fsuid can be
> separated from the task_struct.
>
> Signed-off-by: David Howells <[EMAIL PROTECTED]>
Reviewed-by: James Morris <[EMAIL PROTECTED]>
--
Jam
is doing spin_lock() on an
> uninitialised (or already locked) spinlock.
Perplexing.
Do you have all of the lock debugging enabled?
- James
--
James Morris
<[EMAIL PROTECTED]>
Please review.
Tested with SELinux in enforcing mode.
---
All instances of rw_verify_area() are followed by a call to
security_file_permission(), so just call the latter from the former.
Signed-off-by: James Morris <[EMAIL PROTECTED]>
---
fs/compat.c |4 ---
fs/read_write.c
nused err
> parameter. The conversion is similar to the one performed by Al Viro for the
> security_getprocattr hook.
>
> Signed-off-by: David P. Quigley <[EMAIL PROTECTED]>
Acked-by: James Morris <[EMAIL PROTECTED]>
--
James Morris
<[EMAIL PROTECTED]>
-
To uns
on. In the event that both are inaccessible it
> returns EOPNOTSUPP.
>
> Signed-off-by: David P. Quigley <[EMAIL PROTECTED]>
Acked-by: James Morris <[EMAIL PROTECTED]>
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe lin
On Wed, 31 Oct 2007, David P. Quigley wrote:
> On Sat, 2007-10-27 at 08:14 +1000, James Morris wrote:
> > On Fri, 26 Oct 2007, Serge E. Hallyn wrote:
> >
> > > > It wouldn't be much effort to rebase this patch against Linus's latest
> > > > tr
s.
>
> Yeah it's in 2.6.24. So a rebase will be necessary anyway.
That code may still change -- Arjan's update, for example.
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message t
on. In the event that both are inaccessible it
> returns EOPNOTSUPP.
>
> Signed-off-by: David P. Quigley <[EMAIL PROTECTED]>
Acked-by: James Morris <[EMAIL PROTECTED]>
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe lin
eclarations on one line if possible (the
80-col rule can be broken for this).
But in any case, it looks ok to me.
Acked-by: James Morris <[EMAIL PROTECTED]>
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel"
On Thu, 9 Aug 2007, David Howells wrote:
> James Morris <[EMAIL PROTECTED]> wrote:
>
> > David, I've looked at the code and can't see that you need to access the
> > label itself outside the LSM. Could you instead simply pass the inode
> > pointer aro
On Thu, 9 Aug 2007, David Howells wrote:
> + u32 (*inode_get_secid)(struct inode *inode);
To maintain API consistency, please return an int which only acts as an
error code, and returning the secid via a *u32 function parameter.
- James
--
James Morris
<[EMAIL PROTECTED]
ld you instead simply pass the inode
pointer around?
(I know it's not always possible, but much preferred).
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More
On Thu, 9 Aug 2007, David Howells wrote:
> James Morris <[EMAIL PROTECTED]> wrote:
>
> > > + u32 (*inode_get_secid)(struct inode *inode);
> >
> > To maintain API consistency, please return an int which only acts as an
> > error code, and returning
mailing list subscription information, please see:
http://linux-nfs.org/cgi-bin/mailman/listinfo/labeled-nfs
Prior discussion of this project (which started out as SELinux-specific)
may be found at: http://thread.gmane.org/gmane.linux.nfsv4/5341
--
James Morris
<[EMAIL PROTECTED]>
ROTECTED]>
Acked-by: James Morris <[EMAIL PROTECTED]>
(Will need to check it's ok again after final merge).
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
pathname?
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
ce labeling.
Some of us took the time to perform analysis and then provide feedback on
this, in good faith.
The underlying issues only came up again in response to an inflammatory
post by Lars. If you want to avoid discussions of AppArmor's design, then
I suggest taking it up with those
pretty lame.
I think this raises substantial questions about the value of AppArmor.
What is the point of having a jail if it leaves gaping holes that
malicious code could use to escape?
And why isn't this documented clearly, with the implications fully
explained?" - David Wag
ed by
the documentation, and its policy does not reflect its actual confinement
properties. That's kind of a technical issue, right?
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
simply does not and can not work is a fairly significant consideration, I
would imagine.
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
On Fri, 15 Jun 2007, Casey Schaufler wrote:
>
> --- James Morris <[EMAIL PROTECTED]> wrote:
>
> > On my system, it takes about 1.2 seconds to label a fully checked out
> > kernel source tree with ~23,000 files in this manner
>
> That's an eternity for th
On Fri, 15 Jun 2007, Seth Arnold wrote:
> The time for restorecon is probably best imagined as a kind of 'du' that
> also updates extended attributes as it does its work. It'd be very
> difficult to improve on this.
restorecon can most definitely be improved.
- James
ecurity
logic. DAC permissions don't change on every file in the subtree when you
mv directories, either.
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
rmission changes as a result.
OTOH, you've performed your labeling up front, and don't have to
effectively relabel each file each time on each access, which is what
you're really doing with pathname labeling.
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from th
an idea of the cost by running something like:
$ time find /usr/src/linux | xargs setfattr -n user.foo -v bar
On my system, it takes about 1.2 seconds to label a fully checked out
kernel source tree with ~23,000 files in this manner, on a stock standard
ext3 filesystem with a SATA drive.
- Ja
ies, to say, just those running as
user_t in directories labeled as public_html_t (or whatever).
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
beling).
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
. There is no confinement beyond
that.
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
ct 'sysadmin' has:
read access to /etc/shadow
read/write access to /views/sysadmin/etc/shadow
where the objects referenced by the paths are identical and visible to the
subject along both paths, in keeping with your description of "policy may
allow access to some locations but
ut
> not to others. That's not a hole.
I don't know what else you'd call it.
Would you mind providing some concrete examples of how such a model would
be useful?
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsub
On Wed, 18 Apr 2007, Crispin Cowan wrote:
> James Morris wrote:
> > On Tue, 17 Apr 2007, Alan Cox wrote:
> >
> >> I'm not sure if AppArmor can be made good security for the general case,
> >> but it is a model that works in the limited http environmen
ing accessed, you can't protect
against software flaws, which has been a pretty fundamental and widely
understood requirement in general computing for at least a decade.
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscrib
at confining exposed applications.
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
strict existing access
control.
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
way.
Thanks,
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
or trades run-time performance to grant reduced administrative work.
The upfront labeling cost of labeled MAC is not characteristically
different to that of traditional DAC labeling. Ideally, an SELinux system
is installed from scratch with its security labels as well as DAC
attributes, with th
On Fri, 8 Jul 2005, Arjan van de Ven wrote:
> why not?
> If your /etc/shadow has no selinux context you've lost already :0
No, the kernel will map it to something safe.
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubsc
41 matches
Mail list logo
