On Thu, Jan 10, 2013 at 11:34:39AM -0500, Eric Paris wrote:
> This is not the point I am arguing. This is not about LSMs, how hard
> they are to configure, or how to 'fix' them. It certainly isn't about
> how one LSM is better, easier, or superior to another. This is about
> getting more
On Thu, Jan 10, 2013 at 11:34:39AM -0500, Eric Paris wrote:
This is not the point I am arguing. This is not about LSMs, how hard
they are to configure, or how to 'fix' them. It certainly isn't about
how one LSM is better, easier, or superior to another. This is about
getting more
On Sunday 20 January 2013 19:00:46 Eric W. Biederman wrote:
> Carlos O'Donell writes:
> > On 01/09/2013 04:09 PM, Eric Paris wrote:
> >> On Wed, 2013-01-09 at 21:59 +0100, Jakub Jelinek wrote:
> >>> On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
> I'm suggesting that the
ebied...@xmission.com (Eric W. Biederman) writes:
> Carlos O'Donell writes:
>
>> On 01/09/2013 04:09 PM, Eric Paris wrote:
>>> On Wed, 2013-01-09 at 21:59 +0100, Jakub Jelinek wrote:
On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
> I'm suggesting that the string
Carlos O'Donell writes:
> On 01/09/2013 04:09 PM, Eric Paris wrote:
>> On Wed, 2013-01-09 at 21:59 +0100, Jakub Jelinek wrote:
>>> On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
I'm suggesting that the string returned by get_extended_error_info()
ought to be the audit
Carlos O'Donell car...@systemhalted.org writes:
On 01/09/2013 04:09 PM, Eric Paris wrote:
On Wed, 2013-01-09 at 21:59 +0100, Jakub Jelinek wrote:
On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
I'm suggesting that the string returned by get_extended_error_info()
ought to be
ebied...@xmission.com (Eric W. Biederman) writes:
Carlos O'Donell car...@systemhalted.org writes:
On 01/09/2013 04:09 PM, Eric Paris wrote:
On Wed, 2013-01-09 at 21:59 +0100, Jakub Jelinek wrote:
On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
I'm suggesting that the string
On Sunday 20 January 2013 19:00:46 Eric W. Biederman wrote:
Carlos O'Donell writes:
On 01/09/2013 04:09 PM, Eric Paris wrote:
On Wed, 2013-01-09 at 21:59 +0100, Jakub Jelinek wrote:
On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
I'm suggesting that the string returned by
* Eric Paris (epa...@redhat.com) wrote:
> Getting an EPERM/EACCES in userspace really kinda blows. As a user you
> don't have any idea why you got it. It could be SELinux, it could be
> rwx bits on the file, it could be a missing capability, it could be an
> ACL, it could be who knows what.
* Eric Paris (epa...@redhat.com) wrote:
Getting an EPERM/EACCES in userspace really kinda blows. As a user you
don't have any idea why you got it. It could be SELinux, it could be
rwx bits on the file, it could be a missing capability, it could be an
ACL, it could be who knows what. We'd
On 01/09/2013 10:04:23 AM, Eric Paris wrote:
Getting an EPERM/EACCES in userspace really kinda blows. As a user
you
don't have any idea why you got it. It could be SELinux, it could be
rwx bits on the file, it could be a missing capability, it could be an
ACL, it could be who knows what.
Eric Paris wrote:
> On Fri, 2013-01-11 at 00:14 +0900, Tetsuo Handa wrote:
> > The reason I think is that people turn off LSMs because they are using LSMs
> > without understanding "what the current configuration is" and/or "how to
> > change
> > configuration". People do not spend (or cannot
On Thu, 2013-01-10 at 11:34 -0500, Eric Paris wrote:
> Friendlier/more complete error messages would eliminate an awful lot of
> digging around trying to figure *what* the problem is, preparatory to
> discerning *where* the problem is and *how* to fix it.
Agreed, add to the mix of existing
On Thu, 2013-01-10 at 11:34 -0500, Eric Paris wrote:
Friendlier/more complete error messages would eliminate an awful lot of
digging around trying to figure *what* the problem is, preparatory to
discerning *where* the problem is and *how* to fix it.
Agreed, add to the mix of existing issues,
Eric Paris wrote:
On Fri, 2013-01-11 at 00:14 +0900, Tetsuo Handa wrote:
The reason I think is that people turn off LSMs because they are using LSMs
without understanding what the current configuration is and/or how to
change
configuration. People do not spend (or cannot afford spending)
On 01/09/2013 10:04:23 AM, Eric Paris wrote:
Getting an EPERM/EACCES in userspace really kinda blows. As a user
you
don't have any idea why you got it. It could be SELinux, it could be
rwx bits on the file, it could be a missing capability, it could be an
ACL, it could be who knows what.
On Fri, 2013-01-11 at 00:14 +0900, Tetsuo Handa wrote:
> The reason I think is that people turn off LSMs because they are using LSMs
> without understanding "what the current configuration is" and/or "how to
> change
> configuration". People do not spend (or cannot afford spending) resources for
Eric Paris wrote:
> On systems with a strict security policy worried about such things this
> would quite reasonably need to be disabled. But most of the reason
> people turn off LSMs is because it gets in the way and they get pissed
> getting an EPERM, checking rwx bits, having no idea WTF
On Fri, 2013-01-11 at 00:14 +0900, Tetsuo Handa wrote:
The reason I think is that people turn off LSMs because they are using LSMs
without understanding what the current configuration is and/or how to
change
configuration. People do not spend (or cannot afford spending) resources for
Eric Paris wrote:
On systems with a strict security policy worried about such things this
would quite reasonably need to be disabled. But most of the reason
people turn off LSMs is because it gets in the way and they get pissed
getting an EPERM, checking rwx bits, having no idea WTF happened,
On 01/09/2013 04:09 PM, Eric Paris wrote:
> On Wed, 2013-01-09 at 21:59 +0100, Jakub Jelinek wrote:
>> On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
>>> I'm suggesting that the string returned by get_extended_error_info()
>>> ought to be the audit record the system call would
On Wed, 2013-01-09 at 21:59 +0100, Jakub Jelinek wrote:
> On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
> > I'm suggesting that the string returned by get_extended_error_info()
> > ought to be the audit record the system call would generate, regardless
> > of whether the audit
On 1/9/2013 1:13 PM, Eric Paris wrote:
> On Wed, 2013-01-09 at 12:53 -0800, Casey Schaufler wrote:
>
>> Let me try again, I think I didn't quite get the idea across.
>>
>> I'm suggesting that the string returned by get_extended_error_info()
>> ought to be the audit record the system call would
On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
> I'm suggesting that the string returned by get_extended_error_info()
> ought to be the audit record the system call would generate, regardless
> of whether the audit system would emit it or not.
What system call would that info be
On Wed, 2013-01-09 at 12:53 -0800, Casey Schaufler wrote:
> Let me try again, I think I didn't quite get the idea across.
>
> I'm suggesting that the string returned by get_extended_error_info()
> ought to be the audit record the system call would generate, regardless
> of whether the audit
On 1/9/2013 12:59 PM, Jakub Jelinek wrote:
> On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
>> I'm suggesting that the string returned by get_extended_error_info()
>> ought to be the audit record the system call would generate, regardless
>> of whether the audit system would emit
On 1/9/2013 12:32 PM, Eric Paris wrote:
> On Wed, 2013-01-09 at 12:14 -0800, Casey Schaufler wrote:
>> On 1/9/2013 11:43 AM, Eric Paris wrote:
>>> I know many people are worried about information leaks, so I'll right up
>>> front say lets add the sysctl to disable the interface for those who are
On Wed, 2013-01-09 at 12:14 -0800, Casey Schaufler wrote:
> On 1/9/2013 11:43 AM, Eric Paris wrote:
> > I know many people are worried about information leaks, so I'll right up
> > front say lets add the sysctl to disable the interface for those who are
> > concerned about the metadata
On 1/9/2013 11:43 AM, Eric Paris wrote:
>> On Wed, 2013-01-09 at 11:04 -0500, Eric Paris wrote:
>>> Getting an EPERM/EACCES in userspace really kinda blows. As a user you
>>> don't have any idea why you got it.
> Stephen Smalley wrote:
>> What if the denial was due to lacking sufficient
>On Wed, 2013-01-09 at 11:04 -0500, Eric Paris wrote:
> >Getting an EPERM/EACCES in userspace really kinda blows. As a user you
> >don't have any idea why you got it.
Stephen Smalley wrote:
> What if the denial was due to lacking sufficient permission to stat
> the file (in which case you
Getting an EPERM/EACCES in userspace really kinda blows. As a user you
don't have any idea why you got it. It could be SELinux, it could be
rwx bits on the file, it could be a missing capability, it could be an
ACL, it could be who knows what. We'd like to start figuring out the
who knows what
Getting an EPERM/EACCES in userspace really kinda blows. As a user you
don't have any idea why you got it. It could be SELinux, it could be
rwx bits on the file, it could be a missing capability, it could be an
ACL, it could be who knows what. We'd like to start figuring out the
who knows what
On Wed, 2013-01-09 at 11:04 -0500, Eric Paris wrote:
Getting an EPERM/EACCES in userspace really kinda blows. As a user you
don't have any idea why you got it.
Stephen Smalley wrote:
What if the denial was due to lacking sufficient permission to stat
the file (in which case you shouldn't
On 1/9/2013 11:43 AM, Eric Paris wrote:
On Wed, 2013-01-09 at 11:04 -0500, Eric Paris wrote:
Getting an EPERM/EACCES in userspace really kinda blows. As a user you
don't have any idea why you got it.
Stephen Smalley wrote:
What if the denial was due to lacking sufficient permission to stat
On Wed, 2013-01-09 at 12:14 -0800, Casey Schaufler wrote:
On 1/9/2013 11:43 AM, Eric Paris wrote:
I know many people are worried about information leaks, so I'll right up
front say lets add the sysctl to disable the interface for those who are
concerned about the metadata information leak.
On 1/9/2013 12:32 PM, Eric Paris wrote:
On Wed, 2013-01-09 at 12:14 -0800, Casey Schaufler wrote:
On 1/9/2013 11:43 AM, Eric Paris wrote:
I know many people are worried about information leaks, so I'll right up
front say lets add the sysctl to disable the interface for those who are
concerned
On 1/9/2013 12:59 PM, Jakub Jelinek wrote:
On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
I'm suggesting that the string returned by get_extended_error_info()
ought to be the audit record the system call would generate, regardless
of whether the audit system would emit it or
On Wed, 2013-01-09 at 12:53 -0800, Casey Schaufler wrote:
Let me try again, I think I didn't quite get the idea across.
I'm suggesting that the string returned by get_extended_error_info()
ought to be the audit record the system call would generate, regardless
of whether the audit system
On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
I'm suggesting that the string returned by get_extended_error_info()
ought to be the audit record the system call would generate, regardless
of whether the audit system would emit it or not.
What system call would that info be
On 1/9/2013 1:13 PM, Eric Paris wrote:
On Wed, 2013-01-09 at 12:53 -0800, Casey Schaufler wrote:
Let me try again, I think I didn't quite get the idea across.
I'm suggesting that the string returned by get_extended_error_info()
ought to be the audit record the system call would generate,
On Wed, 2013-01-09 at 21:59 +0100, Jakub Jelinek wrote:
On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
I'm suggesting that the string returned by get_extended_error_info()
ought to be the audit record the system call would generate, regardless
of whether the audit system
On 01/09/2013 04:09 PM, Eric Paris wrote:
On Wed, 2013-01-09 at 21:59 +0100, Jakub Jelinek wrote:
On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
I'm suggesting that the string returned by get_extended_error_info()
ought to be the audit record the system call would generate,
42 matches
Mail list logo
