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
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 said
Thanks for your comments Casey and Kyle.
Just to clarify what I meant:
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
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
to actually implement.
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 or
Hello.
Kyle Moffett wrote:
Part of the reason that Fedora has a large quantity of that
restorecon and restorecond crap is that there is a certain amount of
broken binary software needing executable stack/heap (such as
flashplayer), programs without comprehensive or complete policies,
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_ is flawed;
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 accessed
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
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
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 other
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
--- 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] convention,
Sounds
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
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 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.
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
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
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: AppArmor decides
based
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 the
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
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
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 in.
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
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 have
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 checks
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 ?
27 matches
Mail list logo
