All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Emelyanov <xemul@openvz.org>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: Greg KH <greg@kroah.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, menage@google.com,
	sukadev@us.ibm.com, Al Viro <viro@zeniv.linux.org.uk>,
	linux-security-module@vger.kernel.org,
	Stephen Smalley <sds@tycho.nsa.gov>
Subject: Re: [PATCH 5/9] Make use of permissions, returned by kobj_lookup
Date: Wed, 12 Mar 2008 16:36:51 +0300	[thread overview]
Message-ID: <47D7DC73.5020103@openvz.org> (raw)
In-Reply-To: <20080312130904.GB8308@sergelap.austin.ibm.com>

Serge E. Hallyn wrote:
> Quoting Pavel Emelyanov (xemul@openvz.org):
>> Greg KH wrote:
>>> On Tue, Mar 11, 2008 at 12:57:55PM +0300, Pavel Emelyanov wrote:
>>>> Besides, I've measured some things - the lat_syscall test for open from 
>>>> lmbench test suite and the nptl perf test. Here are the results:
>>>>
>>>>         sec     nosec
>>>> open    3.0980s  3.0709s
>>>> nptl    2.7746s  2.7710s
>>>>
>>>> So we have 0.88% loss in open and ~0.15% with nptl. I know, this is not that
>>>> much, but it is noticeable. Besides, this is only two tests, digging deeper
>>>> may reveal more.
>>> I think that is in the noise of sampling if you run that test many more
>>> times.
>> These numbers are average values of 20 runs of each test. I didn't
>> provide the measurement accuracy, but the abs(open.sec - open.nosec)
>> is greater than it.
>>
>>>> Let alone the fact that simply turning the CONFIG_SECURITY to 'y' puts +8Kb 
>>>> to the vmlinux...
>>>>
>>>> I think, I finally agree with you and Al Viro, that the kobj mapper is 
>>>> not the right place to put the filtering, but taking the above numbers 
>>>> into account, can we put the "hooks" into the #else /* CONFIG_SECURITY */
>>>> versions of security_inode_permission/security_file_permission/etc?
>>> Ask the security module interface maintainers about this, not me :)
>> OK :) Thanks for your time, Greg.
>>
>> So, Serge, since you already have a LSM-based version, maybe you can
>> change it with the proposed "fix" and send it to LSM maintainers for
>> review?
> 
> To take the point of view of someone who neither wants containers nor
> LSM but just a fast box,
> 
> you're asking me to introduce LSM hooks for the !SECURITY case?  :)

No exactly. Look at security_ptrace, security_task_kill or 
security_vm_enough_memory for !SECURITY cases. I wanted to see similar 
for device access list not to replace selinux with this small "security
module" and not to carry this huge LSM for our modest purposes.

> I can give it a shot, but I expect some complaints.  Now at least the
> _mknod hook shouldn't be a hotpath,  and I suppose I can add yet
> an #ifdef inside the !SECURITY version of security_inode_permission().
> I still expect some complaints though.  I'll send something soon.
> 
> thanks,
> -serge
> 
>>> good luck,
>>>
>>> greg k-h
>>>
> 


  parent reply	other threads:[~2008-03-12 13:38 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-05 17:23 [PATCH 0/9] Devices accessibility control group (v4) Pavel Emelyanov
2008-03-05 17:25 ` [PATCH 1/9] Avoid magic constants in drivers/base/map.c Pavel Emelyanov
2008-03-05 17:28 ` [PATCH 2/9] Cleanup the get_gendisk() a bit Pavel Emelyanov
2008-03-05 17:32 ` [PATCH 3/9] Add a mode on the struct probe Pavel Emelyanov
2008-03-05 17:34 ` [PATCH 4/9] Make kobj_lookup() return the mapping's permissions Pavel Emelyanov
2008-03-05 17:37 ` [PATCH 5/9] Make use of permissions, returned by kobj_lookup Pavel Emelyanov
2008-03-06  1:13   ` Andrew Morton
2008-03-06  8:48     ` Pavel Emelyanov
2008-03-07  9:22     ` Pavel Emelyanov
2008-03-07  9:35       ` Andrew Morton
2008-03-07  9:52         ` Pavel Emelyanov
2008-03-07 15:59           ` Greg KH
2008-03-07 16:38             ` Pavel Emelyanov
2008-03-07 17:01               ` Greg KH
2008-03-07 17:08                 ` Al Viro
2008-03-07 17:35                 ` Serge E. Hallyn
2008-03-07 17:57                   ` Casey Schaufler
2008-03-07 18:30                     ` Serge E. Hallyn
2008-03-07 19:46                       ` Stephen Smalley
2008-03-07 20:57                         ` Casey Schaufler
2008-03-07 21:32                           ` Serge E. Hallyn
2008-03-07 18:14                   ` Greg KH
2008-03-07 18:50                     ` Serge E. Hallyn
2008-03-08  6:04                       ` Greg KH
2008-03-08 21:47                         ` Serge E. Hallyn
2008-03-09  3:15                           ` Greg KH
2008-03-10 20:35                             ` Serge E. Hallyn
2008-03-11  9:57                 ` Pavel Emelyanov
2008-03-11 17:36                   ` Greg KH
2008-03-12  8:26                     ` Pavel Emelyanov
2008-03-12 13:09                       ` Serge E. Hallyn
2008-03-12 13:18                         ` Stephen Smalley
2008-03-12 13:27                           ` Stephen Smalley
2008-03-12 14:18                             ` Serge E. Hallyn
2008-03-12 14:15                           ` Serge E. Hallyn
2008-03-12 16:21                           ` Casey Schaufler
2008-03-12 13:36                         ` Pavel Emelyanov [this message]
2008-03-05 17:40 ` [PATCH 6/9] Extend the drivers/base/map.c functionality Pavel Emelyanov
2008-03-05 17:43 ` [PATCH 7/9] Provide functions to manipulate char device mappings Pavel Emelyanov
2008-03-05 17:46 ` [PATCH 8/9] Provide functions to manipulate block " Pavel Emelyanov
2008-03-05 17:47 ` [PATCH 9/9] Devices accessibility control group itself Pavel Emelyanov
2008-03-06  2:02   ` Greg KH
2008-03-06  1:55 ` [PATCH 0/9] Devices accessibility control group (v4) Greg KH
2008-03-06  3:15   ` Serge E. Hallyn
2008-03-06  4:34     ` Greg KH
2008-03-06  8:36       ` Pavel Emelyanov
2008-03-07  4:58         ` Greg KH
2008-03-07  8:42         ` Pavel Machek
2008-03-07  8:54           ` Pavel Emelyanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47D7DC73.5020103@openvz.org \
    --to=xemul@openvz.org \
    --cc=akpm@linux-foundation.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=menage@google.com \
    --cc=sds@tycho.nsa.gov \
    --cc=serue@us.ibm.com \
    --cc=sukadev@us.ibm.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.