On Sun, 10 Jun 2007, Pavel Machek 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 environment
(eg .htaccess) and is something people can play with and hack on and may
be possible to configure to be very secure.
Pe
Hi!
> 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 environment
> (eg .htaccess) and is something people can play with and hack on and may
> be possible to configure to be very secure.
>
> >>>Perhaps
On Sat, 9 Jun 2007, Pavel Machek wrote:
Hi!
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 environment
(eg .htaccess) and is something people can play with and hack on and may
be possible to configure to be very secure.
Hi!
> >> 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 environment
> >> (eg .htaccess) and is something people can play with and hack on and may
> >> be possible to configure to be very secure.
> >>
> > Perhaps -
On Sat, 9 Jun 2007, Kyle Moffett wrote:
On Jun 09, 2007, at 13:32:05, [EMAIL PROTECTED] wrote:
On Sat, 9 Jun 2007, Kyle Moffett wrote:
> On Jun 09, 2007, at 12:46:40, [EMAIL PROTECTED] wrote:
> > so as I understand this with SELinux you will have lots of labels
> > around your system (more as
On Jun 09, 2007, at 13:32:05, [EMAIL PROTECTED] wrote:
On Sat, 9 Jun 2007, Kyle Moffett wrote:
On Jun 09, 2007, at 12:46:40, [EMAIL PROTECTED] wrote:
so as I understand this with SELinux you will have lots of labels
around your system (more as you lock down the system more) you
need to defin
On Sat, 9 Jun 2007, Kyle Moffett wrote:
On Jun 09, 2007, at 12:46:40, [EMAIL PROTECTED] wrote:
On Sat, 9 Jun 2007, Kyle Moffett wrote:
> Typical "targetted" policies leave all user logins as unrestricted,
> adding security for daemons but not getting in the way of users who would
> otherwise
On Jun 09, 2007, at 12:46:40, [EMAIL PROTECTED] wrote:
On Sat, 9 Jun 2007, Kyle Moffett wrote:
Typical "targetted" policies leave all user logins as
unrestricted, adding security for daemons but not getting in the
way of users who would otherwise turn SELinux off. On the other
hand, a targ
We need to export vfs_lease so nfsd can call it.
Marc.
"J. Bruce Fields" <[EMAIL PROTECTED]> wrote on 06/08/2007 03:14:53
PM:
> From: J. Bruce Fields <[EMAIL PROTECTED]>
>
> We've been using the convention that vfs_foo is the function that calls
> a filesystem-specific foo method if it exists,
On Sat, 9 Jun 2007, Kyle Moffett wrote:
On Jun 09, 2007, at 01:18:40, [EMAIL PROTECTED] wrote:
SELinux is like a default allow IPS system, you have to describe EVERYTHING
to the system so that it knows what to allow and what to stop.
WRONG. You clearly don't understand SELinux at all. Try b
On Sat, 9 Jun 2007 17:17:57 +0200
Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
> On Saturday 09 June 2007 10:10, Sean wrote:
> > Clinging to the current AA implementation instead of honestly considering
> > reasonable alternatives does not inspire confidence or teamwork.
>
> What you imply is p
This is the return code that setlease() currently returns when the lease
can not be obtained. Although ENOTSUPP would be more accurately describing
the error it will be a new return code from setlease() that is currently
not expected by callers to setlease(), but either return code should work.
On Jun 09, 2007, at 01:18:40, [EMAIL PROTECTED] wrote:
SELinux is like a default allow IPS system, you have to describe
EVERYTHING to the system so that it knows what to allow and what to
stop.
WRONG. You clearly don't understand SELinux at all. Try booting in
enforcing mode with an empt
[EMAIL PROTECTED] wrote:
On Sat, 9 Jun 2007, Sean wrote:
what SELinux cannot do is figure out what label to assign a new file.
Nit: SELinux figures out what to label new files fine, just not based on
the name. This works in most cases, eg., when user_t creates a file in
/tmp it becomes use
On Saturday 09 June 2007 10:10, Sean wrote:
> Clinging to the current AA implementation instead of honestly considering
> reasonable alternatives does not inspire confidence or teamwork.
What you imply is pretty insulting. I can assure you we looked into many
possible implementation choices, and
On Saturday 09 June 2007 02:17, Greg KH wrote:
> On Sat, Jun 09, 2007 at 12:03:57AM +0200, Andreas Gruenbacher wrote:
> > AppArmor is meant to be relatively easy to understand, manage, and
> > customize, and introducing a labels layer wouldn't help these goals.
>
> Woah, that describes the usersp
Hi!
> >> Some may infer otherwise from your document.
> >>
> > Not only that, the implication that secrecy is only useful to
> > intelligence agencies is pretty funny.
> That was not the claim. Rather, that intelligence agencies have a very
> strong need for privacy, and will go to greater le
Hi,
On Fri, 2007-06-08 at 18:14 -0400, J. Bruce Fields wrote:
> From: Marc Eshel <[EMAIL PROTECTED]>
>
> Since gfs2 can't prevent conflicting opens or leases on other nodes, we
> probably shouldn't allow it to give out leases at all.
>
> Put the newly defined lease operation into use in gfs2 by
On Saturday 09 June 2007 14:58, Pavel Machek wrote:
> > > How will kernel work with very long paths? I'd suspect some problems,
> > > if path is 1MB long and I attempt to print it in /proc
> > > somewhere.
> >
> > Pathnames are only used for informational purposes in the kernel, except
> > in App
Hi!
> > How will kernel work with very long paths? I'd suspect some problems,
> > if path is 1MB long and I attempt to print it in /proc
> > somewhere.
>
> Pathnames are only used for informational purposes in the kernel, except in
> AppArmor of course. /proc only uses pathnames in a few places,
On Sat, 09 Jun 2007 11:30:04 +1000
Herbert Xu <[EMAIL PROTECTED]> wrote:
> Please cc networking patches to [EMAIL PROTECTED]
>
> Jeff Layton <[EMAIL PROTECTED]> wrote:
> >
> > The following patch is a first stab at removing this need. It makes it
> > so that in tcp_recvmsg() we also check kthrea
On Sat, 9 Jun 2007 01:06:09 -0700 (PDT)
[EMAIL PROTECTED] wrote:
> but the SELinux API's are not the core security API's in Linux, the LSM
> API's are. and AA is useing the LSM API's (extending them where they and
> SELinux don't do what's needed)
>
Calling LSM "core" and pretending that SELi
On Sat, 9 Jun 2007, Sean wrote:
remember that the security hooks in the kernel are not SELinux API's, they
are the Loadable Security Model API. What the AA people are asking for is
for the LSM API to be modified enough to let their code run (after that
(and working in parallel) they will work on
On Sat, 9 Jun 2007 00:13:22 -0700 (PDT)
[EMAIL PROTECTED] wrote:
> did you read my explination of the analogy?
It was a rather poor analogy i'm afraid. But the point i make still stands.
So far you've failed to show any reason SELinux can't be reasonably extended
to handle all the features you c
On Sat, 9 Jun 2007, Sean wrote:
On Fri, 8 Jun 2007 22:18:40 -0700 (PDT)
[EMAIL PROTECTED] wrote:
the way I would describe the difference betwen AA and SELinux is:
SELinux is like a default allow IPS system, you have to describe
EVERYTHING to the system so that it knows what to allow and what
25 matches
Mail list logo
