2019-06-13 01:52:52 +08:00
|
|
|
=====================
|
2006-08-04 07:45:49 +08:00
|
|
|
NetLabel Introduction
|
2019-06-13 01:52:52 +08:00
|
|
|
=====================
|
|
|
|
|
|
2006-08-04 07:45:49 +08:00
|
|
|
Paul Moore, paul.moore@hp.com
|
|
|
|
|
|
|
|
|
|
August 2, 2006
|
|
|
|
|
|
2019-06-13 01:52:52 +08:00
|
|
|
Overview
|
|
|
|
|
========
|
2006-08-04 07:45:49 +08:00
|
|
|
|
|
|
|
|
NetLabel is a mechanism which can be used by kernel security modules to attach
|
|
|
|
|
security attributes to outgoing network packets generated from user space
|
|
|
|
|
applications and read security attributes from incoming network packets. It
|
|
|
|
|
is composed of three main components, the protocol engines, the communication
|
|
|
|
|
layer, and the kernel security module API.
|
|
|
|
|
|
2019-06-13 01:52:52 +08:00
|
|
|
Protocol Engines
|
|
|
|
|
================
|
2006-08-04 07:45:49 +08:00
|
|
|
|
|
|
|
|
The protocol engines are responsible for both applying and retrieving the
|
|
|
|
|
network packet's security attributes. If any translation between the network
|
|
|
|
|
security attributes and those on the host are required then the protocol
|
|
|
|
|
engine will handle those tasks as well. Other kernel subsystems should
|
|
|
|
|
refrain from calling the protocol engines directly, instead they should use
|
|
|
|
|
the NetLabel kernel security module API described below.
|
|
|
|
|
|
|
|
|
|
Detailed information about each NetLabel protocol engine can be found in this
|
Drop all 00-INDEX files from Documentation/
This is a respin with a wider audience (all that get_maintainer returned)
and I know this spams a *lot* of people. Not sure what would be the correct
way, so my apologies for ruining your inbox.
The 00-INDEX files are supposed to give a summary of all files present
in a directory, but these files are horribly out of date and their
usefulness is brought into question. Often a simple "ls" would reveal
the same information as the filenames are generally quite descriptive as
a short introduction to what the file covers (it should not surprise
anyone what Documentation/sched/sched-design-CFS.txt covers)
A few years back it was mentioned that these files were no longer really
needed, and they have since then grown further out of date, so perhaps
it is time to just throw them out.
A short status yields the following _outdated_ 00-INDEX files, first
counter is files listed in 00-INDEX but missing in the directory, last
is files present but not listed in 00-INDEX.
List of outdated 00-INDEX:
Documentation: (4/10)
Documentation/sysctl: (0/1)
Documentation/timers: (1/0)
Documentation/blockdev: (3/1)
Documentation/w1/slaves: (0/1)
Documentation/locking: (0/1)
Documentation/devicetree: (0/5)
Documentation/power: (1/1)
Documentation/powerpc: (0/5)
Documentation/arm: (1/0)
Documentation/x86: (0/9)
Documentation/x86/x86_64: (1/1)
Documentation/scsi: (4/4)
Documentation/filesystems: (2/9)
Documentation/filesystems/nfs: (0/2)
Documentation/cgroup-v1: (0/2)
Documentation/kbuild: (0/4)
Documentation/spi: (1/0)
Documentation/virtual/kvm: (1/0)
Documentation/scheduler: (0/2)
Documentation/fb: (0/1)
Documentation/block: (0/1)
Documentation/networking: (6/37)
Documentation/vm: (1/3)
Then there are 364 subdirectories in Documentation/ with several files that
are missing 00-INDEX alltogether (and another 120 with a single file and no
00-INDEX).
I don't really have an opinion to whether or not we /should/ have 00-INDEX,
but the above 00-INDEX should either be removed or be kept up to date. If
we should keep the files, I can try to keep them updated, but I rather not
if we just want to delete them anyway.
As a starting point, remove all index-files and references to 00-INDEX and
see where the discussion is going.
Signed-off-by: Henrik Austad <henrik@austad.us>
Acked-by: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Just-do-it-by: Steven Rostedt <rostedt@goodmis.org>
Reviewed-by: Jens Axboe <axboe@kernel.dk>
Acked-by: Paul Moore <paul@paul-moore.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
Cc: [Almost everybody else]
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2018-09-04 06:15:23 +08:00
|
|
|
directory.
|
2006-08-04 07:45:49 +08:00
|
|
|
|
2019-06-13 01:52:52 +08:00
|
|
|
Communication Layer
|
|
|
|
|
===================
|
2006-08-04 07:45:49 +08:00
|
|
|
|
|
|
|
|
The communication layer exists to allow NetLabel configuration and monitoring
|
|
|
|
|
from user space. The NetLabel communication layer uses a message based
|
|
|
|
|
protocol built on top of the Generic NETLINK transport mechanism. The exact
|
|
|
|
|
formatting of these NetLabel messages as well as the Generic NETLINK family
|
2007-05-09 14:57:56 +08:00
|
|
|
names can be found in the 'net/netlabel/' directory as comments in the
|
2006-08-04 07:45:49 +08:00
|
|
|
header files as well as in 'include/net/netlabel.h'.
|
|
|
|
|
|
2019-06-13 01:52:52 +08:00
|
|
|
Security Module API
|
|
|
|
|
===================
|
2006-08-04 07:45:49 +08:00
|
|
|
|
|
|
|
|
The purpose of the NetLabel security module API is to provide a protocol
|
|
|
|
|
independent interface to the underlying NetLabel protocol engines. In addition
|
|
|
|
|
to protocol independence, the security module API is designed to be completely
|
|
|
|
|
LSM independent which should allow multiple LSMs to leverage the same code
|
|
|
|
|
base.
|
|
|
|
|
|
|
|
|
|
Detailed information about the NetLabel security module API can be found in the
|
|
|
|
|
'include/net/netlabel.h' header file as well as the 'lsm_interface.txt' file
|
|
|
|
|
found in this directory.
|
