--- Pavel Machek <[EMAIL PROTECTED]> wrote:
> AA solves less problems than SELinux does.
And vi solves less problems than OpenOffice.
vi is good for a different set of purposes than OpenOffice.
AA and SELinux both aspire to being Security Solutions,
but that does not make either a subset of the
Hi!
(Please preserve cc lists when replying on l-k).
> >Experience over on the Windows side of the fence indicates that "remote bad
> >guys get some local user first" is a *MAJOR* part of the current real-world
> >threat model - the vast majority of successful attacks on end-user boxes
> >these
On Fri 2007-06-01 11:00:50, [EMAIL PROTECTED] wrote:
> On Fri, 1 Jun 2007, [EMAIL PROTECTED] wrote:
>
> >On Thu, 24 May 2007 14:47:27 -, Pavel Machek said:
> >>Yes, if there's significantly more remote bad guys than local bad
> >>guys, and if remote bad guys can't just get some local user firs
On Sat, 02 Jun 2007 12:51:27 PDT, [EMAIL PROTECTED] said:
> this is Security 101 (or even more basic), if you grant a program access
> to do something you can't prevent that program from doing that something.
And Security 102 is "most of the *real* trouble starts when authorized programs
access
On Sat, 2 Jun 2007, [EMAIL PROTECTED] wrote:
On Sat, 02 Jun 2007 07:27:13 PDT, [EMAIL PROTECTED] said:
The type of hardening that AppArmor can provide network-facing daemons is only
protecting the system against attacks that aren't even a large part of the
threat model. Exploiting a broken P
On Sat, 02 Jun 2007 07:27:13 PDT, [EMAIL PROTECTED] said:
> > The type of hardening that AppArmor can provide network-facing daemons is
> > only
> > protecting the system against attacks that aren't even a large part of the
> > threat model. Exploiting a broken PHP script? Happens all the time,
On Sat, 2 Jun 2007, [EMAIL PROTECTED] wrote:
On Sat, 02 Jun 2007 04:30:30 -, David Wagner said:
I don't find the Windows stuff too relevant here.
I'm surprised. The only Windows-specific thing in the whole paragraph is that
the attack described is currently wildly successful. And there *
On Sat, 02 Jun 2007 04:30:30 -, David Wagner said:
> I don't find the Windows stuff too relevant here.
I'm surprised. The only Windows-specific thing in the whole paragraph is that
the attack described is currently wildly successful. And there *have* been
known exploitable bugs in the Linux v
[EMAIL PROTECTED] writes:
>Experience over on the Windows side of the fence indicates that "remote bad
>guys get some local user first" is a *MAJOR* part of the current real-world
>threat model - the vast majority of successful attacks on end-user boxes these
>days start off with either "Get user t
On Fri, 1 Jun 2007, [EMAIL PROTECTED] wrote:
On Thu, 24 May 2007 14:47:27 -, Pavel Machek said:
Yes, if there's significantly more remote bad guys than local bad
guys, and if remote bad guys can't just get some local user first, AA
still has some value.
Experience over on the Windows side
On Thu, 24 May 2007 14:47:27 -, Pavel Machek said:
> Yes, if there's significantly more remote bad guys than local bad
> guys, and if remote bad guys can't just get some local user first, AA
> still has some value.
Experience over on the Windows side of the fence indicates that "remote bad
guy
Hi!
> >> Average users are not supposed to be writing security policy. To be
> >> honest, even average-level system administrators should not be
> >> writing security policy.
> That explains so much! "SELinux: you're too dumb to use it, so just keep
> your hands in your pockets." :-)
>
> App
Hi!
(Please do not drop me from cc list when replying).
> > no, this won't help you much against local users, [...]
>
> Pavel Machek wrote:
> >Hmm, I guess I'd love "it is useless on multiuser boxes" to become
> >standard part of AA advertising.
>
> That's not quite what david@ said. As I und
> >> honest, even average-level system administrators should not be
> >> writing security policy.
> That explains so much! "SELinux: you're too dumb to use it, so just keep
> your hands in your pockets." :-)
Hardly. And there are helper tools
>
> AppArmor was designed to allow your average sys
[EMAIL PROTECTED] wrote:
> On Mon, 28 May 2007 21:54:46 EDT, Kyle Moffett said:
>
>> Average users are not supposed to be writing security policy. To be
>> honest, even average-level system administrators should not be
>> writing security policy.
That explains so much! "SELinux: you're too
Pavel Machek wrote:
>> * Hard links: AppArmor explicitly mediates permission to make a hard
>>
> Unfortunately, aparmor is by design limited to subset of distro
> (network daemons).
That is not true. AppArmor is designed to confine any application you do
not want to trust completely. This
[EMAIL PROTECTED] wrote:
> no, this won't help you much against local users, [...]
Pavel Machek wrote:
>Hmm, I guess I'd love "it is useless on multiuser boxes" to become
>standard part of AA advertising.
That's not quite what david@ said. As I understand it, AppArmor is not
focused on preventi
2007/5/29, Kyle Moffett <[EMAIL PROTECTED]>:
>>> But writing policy with labels are somewhat indirect way (I mean,
>>> we need "ls -Z" or "ps -Z"). Indirect way can cause flaw so we
>>> need a lot of work that is what I wanted to tell.
>>
>> I don't really use "ls -Z" or "ps -Z" when writing SEL
Hi!
> >>>If we want "/etc/shadow" to be the only way to access the shadow file
> >>>we could label the data with "/etc/shadow". Any attempts to access
> >>>this data using a renamed file or link would be denied (attempts to
> >>>link or rename could also be denied).
> >>Eloquently put.
> >>
> >>Ap
On Tue, 29 May 2007, Pavel Machek wrote:
Hi!
If we want "/etc/shadow" to be the only way to access the shadow file
we could label the data with "/etc/shadow". Any attempts to access
this data using a renamed file or link would be denied (attempts to
link or rename could also be denied).
Eloqu
On Mon, 28 May 2007 21:54:46 EDT, Kyle Moffett said:
> Average users are not supposed to be writing security policy. To be
> honest, even average-level system administrators should not be
> writing security policy. It's OK for such sysadmins to tweak
> existing policy to give access to add
Hi!
> > If we want "/etc/shadow" to be the only way to access the shadow file
> > we could label the data with "/etc/shadow". Any attempts to access
> > this data using a renamed file or link would be denied (attempts to
> > link or rename could also be denied).
> Eloquently put.
>
> AppArmor act
On May 28, 2007, at 16:38:38, Pavel Machek wrote:
Kyle Moffett wrote:
I am of the opinion that adding a "name" parameter to the file/
directory create actions would be useful. For example, with such
support you could actually specify a type-transition rule
conditional on a specific name o
On May 28, 2007, at 06:41:11, Toshiharu Harada wrote:
2007/5/27, Kyle Moffett <[EMAIL PROTECTED]>:
If you can't properly manage your labels, then how do you expect
any security at all?
Please read my message again. I didn't say, "This can never be
achieved". I said, "This can not be easily a
Cliffe wrote:
> The following would be used in conjunction with a pathname based
> confinement to try to provide some assurances about what a path refers
> to.
>
> "/etc/shadow" is a name to a sensitive resource. There is no guarantee
> that there are not other ways to access this resource. For exa
Hi!
> >>That's a circular argument, and a fairly trivial one
> >>at that. If you
> >>can't properly manage your labels, then how do you
> >>expect any
> >>security at all?
> >
> >Unfortunately, it's not at all as simple as all that.
> >Toshiharu is quite correct that it isn't always easy
> >
2007/5/27, Kyle Moffett <[EMAIL PROTECTED]>:
On May 27, 2007, at 03:25:27, Toshiharu Harada wrote:
> 2007/5/27, Kyle Moffett <[EMAIL PROTECTED]>:
How is that argument not trivially circular? "Foo has an assumption
that foo-property is always properly defined and maintained." That
could be sa
--- Cliffe <[EMAIL PROTECTED]> wrote:
> >> On the other hand, if you actually want to protect the _data_, then
> tagging the _name_ is flawed; tag the *DATA* instead.
>
> Would it make sense to label the data (resource) with a list of paths
> (names) that can be used to access it?
Program Ac
On May 27, 2007, at 03:25:27, Toshiharu Harada wrote:
2007/5/27, Kyle Moffett <[EMAIL PROTECTED]>:
On May 26, 2007, at 19:08:56, Toshiharu Harada wrote:
2007/5/27, James Morris <[EMAIL PROTECTED]>:
On Sat, 26 May 2007, Kyle Moffett wrote:
AppArmor). On the other hand, if you actually want to
CC trimmed to remove a few poor overloaded inboxes from this tangent.
On May 27, 2007, at 04:34:10, Cliffe wrote:
Kyle wrote:
On the other hand, if you actually want to protect the _data_,
then tagging the _name_ is flawed; tag the *DATA* instead.
Would it make sense to label the data (resou
>> On the other hand, if you actually want to protect the _data_, then
tagging the _name_ is flawed; tag the *DATA* instead.
Would it make sense to label the data (resource) with a list of paths
(names) that can be used to access it?
Therefore the data would be protected against being accesse
2007/5/27, Kyle Moffett <[EMAIL PROTECTED]>:
On May 26, 2007, at 19:08:56, Toshiharu Harada wrote:
> 2007/5/27, James Morris <[EMAIL PROTECTED]>:
>> On Sat, 26 May 2007, Kyle Moffett wrote:
>>> AppArmor). On the other hand, if you actually want to protect
>>> the _data_, then tagging the _name_
On May 26, 2007, at 22:37:02, [EMAIL PROTECTED] wrote:
On Sat, 26 May 2007 22:10:34 EDT, Kyle Moffett said:
On May 26, 2007, at 19:08:56, Toshiharu Harada wrote:
(1) Object labeling has a assumption that labels are always
properly defined and maintained. This can not be easily achieved.
Tha
On Sat, 26 May 2007 22:10:34 EDT, Kyle Moffett said:
> On May 26, 2007, at 19:08:56, Toshiharu Harada wrote:
> > (1) Object labeling has a assumption that labels are always
> > properly defined and maintained. This can not be easily achieved.
>
> That's a circular argument, and a fairly trivial
On May 26, 2007, at 19:08:56, Toshiharu Harada wrote:
2007/5/27, James Morris <[EMAIL PROTECTED]>:
On Sat, 26 May 2007, Kyle Moffett wrote:
AppArmor). On the other hand, if you actually want to protect
the _data_, then tagging the _name_ is flawed; tag the *DATA*
instead.
Bingo.
(This is
On Sat, 26 May 2007 15:58:50 PDT, Casey Schaufler said:
> Fair enough, I don't believe that an argv[0] check ought to
> be used as a security mechanism. I am not convinced that everyone
> would agree with us.
Having seen my share of argv[0]-related security bugs in my years, I have to
agree that i
2007/5/27, James Morris <[EMAIL PROTECTED]>:
On Sat, 26 May 2007, Kyle Moffett wrote:
> AppArmor). On the other hand, if you actually want to protect the _data_,
> then tagging the _name_ is flawed; tag the *DATA* instead.
Bingo.
(This is how traditional Unix DAC has always functioned, and is
--- Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
> On Friday 25 May 2007 21:06, Casey Schaufler wrote:
> > --- Jeremy Maitin-Shepard <[EMAIL PROTECTED]> wrote:
> > > ...
> > > Well, my point was exactly that App Armor doesn't (as far as I know) do
> > > anything to enforce the argv[0] conventio
On Sat, 26 May 2007, Kyle Moffett wrote:
> AppArmor). On the other hand, if you actually want to protect the _data_,
> then tagging the _name_ is flawed; tag the *DATA* instead.
Bingo.
(This is how traditional Unix DAC has always functioned, and is what
SELinux does: object labeling).
- Ja
On Fri, 25 May 2007, Crispin Cowan wrote:
> Finally, AA doesn't care what the contents of the executable are. We
> assume that it is a copy of metasploit or something, and confine it to
> access only the resources that the policy says.
As long as these resources are only files. There is no confi
On Saturday 26 May 2007 15:34, Alan Cox wrote:
> > As such, AA can detect whether you did exec("gzip") or exec("gunzip")
> > and apply the policy relevant to the program. It could apply different
>
> That's not actually useful for programs which link the same binary to
> multiple names because if y
> As such, AA can detect whether you did exec("gzip") or exec("gunzip")
> and apply the policy relevant to the program. It could apply different
That's not actually useful for programs which link the same binary to
multiple names because if you don't consider argv[0] as well I can run
/usr/bin/gzi
On Friday 25 May 2007 21:06, Casey Schaufler wrote:
> --- Jeremy Maitin-Shepard <[EMAIL PROTECTED]> wrote:
> > ...
> > Well, my point was exactly that App Armor doesn't (as far as I know) do
> > anything to enforce the argv[0] convention,
>
> Sounds like an opportunity for improvement then.
Jeez,
On Saturday 26 May 2007 07:20, Kyle Moffett wrote:
> On May 24, 2007, at 14:58:41, Casey Schaufler wrote:
> > On Fedora zcat, gzip and gunzip are all links to the same file. I
> > can imagine (although it is a bit of a stretch) allowing a set of
> > users access to gunzip but not gzip (or the
Casey Schaufler wrote:
> --- Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
>
>> AppArmor cannot assume anything about argv[0],
>>
>> and it would be a really bad idea to change the well-established semantics of
>>
>> argv[0].
>>
>> There is no actual need for looking at argv[0], though: AppArmo
On May 24, 2007, at 14:58:41, Casey Schaufler wrote:
On Fedora zcat, gzip and gunzip are all links to the same file. I
can imagine (although it is a bit of a stretch) allowing a set of
users access to gunzip but not gzip (or the other way around).
That is a COMPLETE straw-man argument. I c
Hello.
Casey Schaufler wrote:
> Sorry, but I don't understand your objection. If AppArmor is configured
> to allow everyone access to /bin/gzip but only some people access to
> /bin/gunzip and (important detail) the single binary uses argv[0]
> as documented and (another important detail) there ar
--- Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
> On Friday 25 May 2007 19:43, Casey Schaufler wrote:
> > [...] but the AppArmor code could certainly check for that in exec by
> > enforcing the argv[0] convention. It would be perfectly reasonable for a
> > system that is so dependent on pathna
On Friday 25 May 2007 19:43, Casey Schaufler wrote:
> [...] but the AppArmor code could certainly check for that in exec by
> enforcing the argv[0] convention. It would be perfectly reasonable for a
> system that is so dependent on pathnames to require that.
Hmm ... that's a strange idea. AppArmor
--- Jeremy Maitin-Shepard <[EMAIL PROTECTED]> wrote:
> ...
> Well, my point was exactly that App Armor doesn't (as far as I know) do
> anything to enforce the argv[0] convention,
Sounds like an opportunity for improvement then.
> nor would it in general
> prevent a confined program from making
Jeremy Maitin-Shepard <[EMAIL PROTECTED]> writes:
> [snip]
> Well, my point was exactly that App Armor doesn't (as far as I know) do
> anything to enforce the argv[0] convention, nor would it in general
> prevent a confined program from making a symlink or hard link. Even
> disregarding that, it
Casey Schaufler <[EMAIL PROTECTED]> writes:
> --- Jeremy Maitin-Shepard <[EMAIL PROTECTED]> wrote:
>> Casey Schaufler <[EMAIL PROTECTED]> writes:
>>
>> > On Fedora zcat, gzip and gunzip are all links to the same file.
>> > I can imagine (although it is a bit of a stretch) allowing a set
>> > of u
--- Jeremy Maitin-Shepard <[EMAIL PROTECTED]> wrote:
> Casey Schaufler <[EMAIL PROTECTED]> writes:
>
> > On Fedora zcat, gzip and gunzip are all links to the same file.
> > I can imagine (although it is a bit of a stretch) allowing a set
> > of users access to gunzip but not gzip (or the other w
Hi,
2007/5/24, James Morris <[EMAIL PROTECTED]>:
I can restate my question and ask why you'd want a security policy like:
Subject '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 visi
Casey Schaufler <[EMAIL PROTECTED]> writes:
> On Fedora zcat, gzip and gunzip are all links to the same file.
> I can imagine (although it is a bit of a stretch) allowing a set
> of users access to gunzip but not gzip (or the other way around).
> There are probably more sophisticated programs that
On Thursday 24 May 2007 20:58, Casey Schaufler wrote:
> On Fedora zcat, gzip and gunzip are all links to the same file.
> I can imagine (although it is a bit of a stretch) allowing a set
> of users access to gunzip but not gzip (or the other way around).
> There are probably more sophisticated prog
On Thursday 24 May 2007 20:40, Al Viro wrote:
> On Thu, May 24, 2007 at 08:10:00PM +0200, Andreas Gruenbacher wrote:
>
> > Read it like this: we don't have a good idea how to support multiple
> > namespaces so far. Currently, we interpret all pathnames relative to the
> > namespace a process is
--- Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
> > 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 not to others" ?
>
> I'm not aware of situations
On Thu, May 24, 2007 at 08:10:00PM +0200, Andreas Gruenbacher wrote:
> Read it like this: we don't have a good idea how to support multiple
> namespaces so far. Currently, we interpret all pathnames relative to the
> namespace a process is in. Confined processes don't have the privilege to
> cr
On Thursday 24 May 2007 15:19, James Morris wrote:
> On Thu, 24 May 2007, Andreas Gruenbacher wrote:
> > > Would you mind providing some concrete examples of how such a model
> > > would be useful?
> >
> > The model is explained, with examples, in the technical documentation at
> > http://forgeftp.
On Thu, 24 May 2007, Andreas Gruenbacher wrote:
> > Would you mind providing some concrete examples of how such a model would
> > be useful?
>
> The model is explained, with examples, in the technical documentation at
> http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/.
I'm asking sp
On Thursday 24 May 2007 03:28, James Morris wrote:
> On Wed, 23 May 2007, Andreas Gruenbacher wrote:
> > This is backwards from what AppArmor does. The policy defines which paths
> > may be accessed; all paths not explicitly listed are denied. If files are
> > mounted at multiple locations, then th
On Wed, 23 May 2007, Andreas Gruenbacher wrote:
> This is backwards from what AppArmor does. The policy defines which paths may
> be accessed; all paths not explicitly listed are denied. If files are mounted
> at multiple locations, then the policy may allow access to some locations but
> not t
On Thursday 12 April 2007 12:12, Al Viro wrote:
> On Thu, Apr 12, 2007 at 02:08:10AM -0700, [EMAIL PROTECTED] wrote:
> > This is needed for computing pathnames in the AppArmor LSM.
>
> Which is an argument against said LSM in current form.
The fundamental model of AppArmor is to perform access che
On Thu, Apr 12, 2007 at 02:08:10AM -0700, [EMAIL PROTECTED] wrote:
> This is needed for computing pathnames in the AppArmor LSM.
Which is an argument against said LSM in current form.
> - error = security_inode_create(dir, dentry, mode);
> + error = security_inode_create(dir, dentry, nd
On Thu, Apr 12, 2007 at 02:08:10AM -0700, [EMAIL PROTECTED] wrote:
> This is needed for computing pathnames in the AppArmor LSM.
>
> Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
> Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
> Signed-off-by: John Johansen <[EMAIL PROTECTED]>
>
> ---
>
This is needed for computing pathnames in the AppArmor LSM.
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Signed-off-by: John Johansen <[EMAIL PROTECTED]>
---
fs/namei.c |2 +-
include/linux/security.h |9 ++---
sec
67 matches
Mail list logo
