[PATCH 0/9] Devices accessibility control group (v4) - Kernel

This is a discussion on [PATCH 0/9] Devices accessibility control group (v4) - Kernel ; 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 ...

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 41 to 47 of 47

Thread: [PATCH 0/9] Devices accessibility control group (v4)

  1. Re: [PATCH 5/9] Make use of permissions, returned by kobj_lookup

    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?

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

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH 5/9] Make use of permissions, returned by kobj_lookup


    On Wed, 2008-03-12 at 08:09 -0500, 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?
    >
    > 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.


    Not sure I'm following the plot here, but please don't do anything that
    will prohibit the use of containers/namespaces with security modules
    like SELinux/Smack. Yes, that's a legitimate use case, and there will
    be people who will want to do that - they serve different but
    complementary purposes (containers are _not_ a substitute for MAC). We
    don't want them to be exclusive of one another.

    --
    Stephen Smalley
    National Security Agency

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [PATCH 5/9] Make use of permissions, returned by kobj_lookup

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

    >


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [PATCH 5/9] Make use of permissions, returned by kobj_lookup


    On Wed, 2008-03-12 at 09:18 -0400, Stephen Smalley wrote:
    > On Wed, 2008-03-12 at 08:09 -0500, 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?
    > >
    > > 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.

    >
    > Not sure I'm following the plot here, but please don't do anything that
    > will prohibit the use of containers/namespaces with security modules
    > like SELinux/Smack. Yes, that's a legitimate use case, and there will
    > be people who will want to do that - they serve different but
    > complementary purposes (containers are _not_ a substitute for MAC). We
    > don't want them to be exclusive of one another.


    Also, note that "real" device labeling and access control (i.e. bind a
    label to a device in the kernel irrespective of what device node is used
    to access it so that a process that can create any device nodes at all
    can't effectively bypass all device access controls just by creating an
    arbitrary node to any device in a type accessible to it) is already
    called out on our kernel todo list for SELinux, and contributions there
    would be welcome.

    --
    Stephen Smalley
    National Security Agency

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [PATCH 5/9] Make use of permissions, returned by kobj_lookup

    Quoting Stephen Smalley (sds@tycho.nsa.gov):
    >
    > On Wed, 2008-03-12 at 08:09 -0500, 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?
    > >
    > > 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.

    >
    > Not sure I'm following the plot here, but please don't do anything that
    > will prohibit the use of containers/namespaces with security modules
    > like SELinux/Smack.


    Absolutely not. There would be a redundant explicit hook in the
    !SECURITY case, but in the SECURITY=y case the regular hooks would be
    used by the device controller.

    I definately consider SELinux/Smack+containers an important case.

    > Yes, that's a legitimate use case, and there will
    > be people who will want to do that - they serve different but
    > complementary purposes (containers are _not_ a substitute for MAC). We
    > don't want them to be exclusive of one another.


    Agreed.

    -serge
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [PATCH 5/9] Make use of permissions, returned by kobj_lookup

    Quoting Stephen Smalley (sds@tycho.nsa.gov):
    >
    > On Wed, 2008-03-12 at 09:18 -0400, Stephen Smalley wrote:
    > > On Wed, 2008-03-12 at 08:09 -0500, 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?
    > > >
    > > > 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.

    > >
    > > Not sure I'm following the plot here, but please don't do anything that
    > > will prohibit the use of containers/namespaces with security modules
    > > like SELinux/Smack. Yes, that's a legitimate use case, and there will
    > > be people who will want to do that - they serve different but
    > > complementary purposes (containers are _not_ a substitute for MAC). We
    > > don't want them to be exclusive of one another.

    >
    > Also, note that "real" device labeling and access control (i.e. bind a
    > label to a device in the kernel irrespective of what device node is used
    > to access it so that a process that can create any device nodes at all
    > can't effectively bypass all device access controls just by creating an
    > arbitrary node to any device in a type accessible to it) is already
    > called out on our kernel todo list for SELinux, and contributions there
    > would be welcome.


    I'll take a look at the todo list (James' I assume). The dev_cgroup lsm
    will have to come first, I'll see about doing the SELinux version as
    well.

    thanks,
    -serge
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [PATCH 5/9] Make use of permissions, returned by kobj_lookup


    --- Stephen Smalley wrote:

    >
    > ...
    >
    > Not sure I'm following the plot here, but please don't do anything that
    > will prohibit the use of containers/namespaces with security modules
    > like SELinux/Smack. Yes, that's a legitimate use case, and there will
    > be people who will want to do that - they serve different but
    > complementary purposes (containers are _not_ a substitute for MAC). We
    > don't want them to be exclusive of one another.


    I agree that we ought to be able to (dare I say it?) stack containers
    and Smack. I have come around 180 degrees regarding the value of
    module stacking and am now convinced that a general mechanism for
    it would be a Good Thing. Both SELinux and Smack already provide
    for stacking capabilities, and I've been asked by another project to
    provide for stacking their module. The alternative to general stacking
    looks more and more like each LSM providing for the modules it is
    willing to stack with, and that could get painful pretty quickly.

    Or, tell me why I'm wrong. I promise to listen nicely. (smiley)


    Casey Schaufler
    casey@schaufler-ca.com
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3