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/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 SELinux policy; I
do
[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 dumb 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
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 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
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
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
--- 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 Access
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 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, what
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/gzip
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
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).
-
--- 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 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 one
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.
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
--- 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 way around).
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 users access to
--- 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 a
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
--- 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 pathnames to
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 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
--- 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 where
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 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 to
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 ?
38 matches
Mail list logo
