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
--- Sean <[EMAIL PROTECTED]> wrote:
> The question is: why not just extend SELinux to include AA functionality
> rather than doing a whole new subsystem.
Because, as hard as it seems for some people to believe,
not everyone wants Type Enforcement. SELinux is a fine
implementation of type enforc
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
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
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
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
On Sat, 9 Jun 2007, Sean wrote:
On Sat, 9 Jun 2007 20:26:57 +0900
Tetsuo Handa <[EMAIL PROTECTED]> wrote:
Sean wrote:
All of a sudden you've implemented the main features of AA with very
few changes to the kernel. It should be more maintainable, and much
easier to get accepted into the kerne
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, 9 Jun 2007 20:26:57 +0900
Tetsuo Handa <[EMAIL PROTECTED]> wrote:
> Sean wrote:
> > All of a sudden you've implemented the main features of AA with very
> > few changes to the kernel. It should be more maintainable, and much
> > easier to get accepted into the kernel.
> Do you agree with
Sean wrote:
> All of a sudden you've implemented the main features of AA with very
> few changes to the kernel. It should be more maintainable, and much
> easier to get accepted into the kernel.
Do you agree with passing "struct vfsmount" to VFS helper functions and LSM
hooks
and introducing d_n
On Sat, 9 Jun 2007 01:03:15 -0700 (PDT)
[EMAIL PROTECTED] wrote:
> becouse the SELinux people don't want to have this in their code for one
> thing.
Tuff nuggies to the SELinux people.. Show them code good enough they'd be
embarrassed to reject.
> you seem to be ignoring the SELinux people who
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, Sean wrote:
On Sat, 9 Jun 2007 00:04:15 -0700 (PDT)
[EMAIL PROTECTED] wrote:
if it was this easy just have SELinux set the label == path
you first need to figure out what the path is. right now this can't be
done, the AA paches provide this capability.
The question is: w
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 00:04:15 -0700 (PDT)
[EMAIL PROTECTED] wrote:
> if it was this easy just have SELinux set the label == path
> you first need to figure out what the path is. right now this can't be
> done, the AA paches provide this capability.
The question is: why not just extend SELinux to
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
On Sat, 9 Jun 2007, Sean wrote:
so are you suggesting that SELinux would call out to userspace for every
file open to get the label for that file?
No, i'm not. You must already have a kernel function in the current
implementation of AA that decides the proper policy for each path. Why
not u
29 matches
Mail list logo
