Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

--- 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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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 days

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

--- 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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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 first, AA

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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, and

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

[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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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." :-) > >

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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 understand it,

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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. :-) AppArmor was

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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 guys

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

[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 to

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

> >> 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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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 admin to

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

[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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

[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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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. > >> >

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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).

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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 actually does

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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).

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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 actually does

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

[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 preventing

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

[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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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 >

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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.

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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 example a

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

--- 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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

>> 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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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_

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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;

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

--- 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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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.

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

--- 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]

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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). -

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

> 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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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,

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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 you don't

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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). -

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

--- 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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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.

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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:

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

--- 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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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.

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

--- 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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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,

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

--- 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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

--- 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).

  1   2   >