The implementation for NETLINK_FIREWALL and NETLINK_IP6_FW protocols
was removed from the kernel in commit
d16cf20e2f2f13411eece7f7fb72c17d141c4a84 ("netfilter: remove ip_queue
support") circa Linux 3.5. Consequently, kernels >= 3.5 should never
perform permission checks on these classes although they remained
defined in the SELinux kernel classmap until the netlink classes
were updated by
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6c6d2e9bde1c1c87a7ead806f8f5e2181d41a652
circa Linux v4.2.
Removing these class definitions would break legacy userspace that relies
upon stable values for the userspace security class definitions since it
will perturb those values by removing classes that preceded them. dbus-daemon
in particular is known to break if its dbus class changes at runtime,
which could occur upon a policy reload that removes these classes.
Fixing this requires ensuring that dbus-daemon looks up the appropriate
class value on each use or upon policy reload, via userspace interfaces
such as selinux_check_access(), string_to_security_class(), and/or
selinux_set_callback(SELINUX_CB_POLICYLOAD, ...) with a callback function
that remaps the class value if needed. Other userspace policy enforcers
are believed to have been updated in recent versions but older versions
may break upon such a change.
Hence, this change renames these classes with obsolete_ prefixes and
removes all rules referencing them from refpolicy, thereby preserving
the class numbering for subsequent classes while making it clear that
these classses are no longer meaningful for modern kernels.
This change does however create a potential compatibility break for
kernels < 3.5, since the policy will cease to define the kernel class
names and therefore the kernel will handle permission checks on the
class based on the handle_unknown setting in policy. For most
Linux distributions, this will default to allow and therefore avoid
breaking userspace but will fail open. For kernels < 2.6.33 (i.e.
the dynamic class/perm discovery support), the presence of a class
in policy with the same number but a different name than the kernel
class will cause the policy load to fail entirely.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
entrypoint and execute_no_trans permissions are only ever checked by the
kernel to regular files. They were added to the chr_file class when
execmod was added (which can be checked on chr_file) to ensure that it
was assigned the same value as for the file class, since the kernel code
always checked FILE__EXECMOD. However, the policy definitions are not
necessary since the kernel and policy values have been decoupled ever
since dynamic class/perm support was introduced and further with the
move of execmod to the common definitions, they were not even needed
in the kernel.
These were removed from the kernel's classmap by
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b424485abe2b16580a178b469917a7b6ee0c152a
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Remove unused permission definitions from SELinux.
Many of these were only ever used in pre-mainline
versions of SELinux, prior to Linux 2.6.0. Some of them
were used in the legacy network or compat_net=1 checks
that were disabled by default in Linux 2.6.18 and
fully removed in Linux 2.6.30.
The corresponding classmap declarations were removed from the
mainline kernel in:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=42a9699a9fa179c0054ea3cf5ad3cc67104a6162
Permissions never used in mainline Linux:
file swapon
filesystem transition
tcp_socket { connectto newconn acceptfrom }
node enforce_dest
unix_stream_socket { newconn acceptfrom }
Legacy network checks, removed in 2.6.30:
socket { recv_msg send_msg }
node { tcp_recv tcp_send udp_recv udp_send rawip_recv rawip_send dccp_recv dccp_send }
netif { tcp_recv tcp_send udp_recv udp_send rawip_recv rawip_send dccp_recv dccp_send }
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
mcstransd never implemented this permission. To keep permission indices
lined up, replace the permission with "unused_perm" to make it clear that
it has no effect.
Add additional entries to support the kernel SCTP implementation
introduced in kernel 4.16
Signed-off-by: Richard Haines <richard_c_haines@btinternet.com>
This patch properly completes the implementation of the MLS file relabel attributes. In the previous patch [http://oss.tresys.com/pipermail/refpolicy/2016-July/008038.html], a new attribute, mlsfilerelabetoclr, was created. There should have been a second attribute, mlsfilerelabel, created instead of overloading mlsfilewrite for this privilege. I concur with creating new attributes for this situation. I have created the patch below.
Signed-off-by: Chad Hanson <dahchanson@gmail.com>
Mirror file/dir approach.
db objects which do not contain other objects at multiple levels are analogous
to files:
db_sequence
db_view
db_procedure
db_language
db_tuple
db_blob
db objects which are capable of holding objects at multiple levels are
analogous to dirs:
db_database
db_schema
db_table
db_column
Define new netlink socket security classes introduced by kernel commit
223ae516404a7a65f09e79a1c0291521c233336e.
Note that this does not remove the long-since obsolete
netlink_firewall_socket and netlink_ip6_fw_socket classes
from refpolicy in case they are still needed for legacy
distribution policies.
Add the new socket classes to socket_class_set.
Update ubac and mls constraints for the new socket classes.
Add allow rules for a few specific known cases (netutils, iptables,
netlabel, ifconfig, udev) in core policy that require access.
Further refinement for the contrib tree will be needed. Any allow
rule previously written on :netlink_socket may need to be rewritten or
duplicated for one of the more specific classes. For now, we retain the
existing :netlink_socket rules for compatibility on older kernels.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
* fix bugs in MLS/MCS
* add connection pooling server support
* foreign data wrapper support
* Add temporary objects support
* redefinition of use permission onto system objects
As identified by Stephan Smalley, the current MLS constraint for the
contains permission of the context class should consider the current
level of a user along with the clearance level so that mls_systemlow
is no longer considered contained in mls_systemhigh.
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.htmlhttp://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
- rework: Add a comment of "deprecated" for deprecated permissions.
- bugfix: MCS policy did not constrain the following permissions.
db_database:{getattr}
db_table:{getattr lock}
db_column:{getattr}
db_procedure:{drop getattr setattr}
db_blob:{getattr import export}
- rework: db_table:{lock} is moved to reader side, because it makes
impossible to refer read-only table with foreign-key constraint.
(FK checks internally acquire explicit locks.)
- bugfix: some of permissions in db_procedure class are allowed
on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
It should allow them on sepgsql_trusted_proc_exec_t.
I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
such kind of confusion, as Chris suggested before.
- rework: we should not allow db_procedure:{install} on the
sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
procedure implicitly.
- bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
but it is required whrn the largeobject is refered.
- bugfix: MLS policy didn't constrain the db_procedure class.
Add MLS constraints for several network related access controls including
the new ingress/egress controls and the older Secmark controls. Based on
the following post to the SELinux Reference Policy mailing list:
* http://oss.tresys.com/pipermail/refpolicy/2009-February/000579.html
The latest revision of the labeled policy patches which enable both labeled
and unlabeled policy support for NetLabel. This revision takes into account
Chris' feedback from the first version and reduces the number of interface
calls in each domain down to two at present: one for unlabeled access, one for
NetLabel access. The older, transport layer specific interfaces, are still
present for use by third-party modules but are not used in the default policy
modules.
trunk: Use netmsg initial SID for MLS-only Netlabel packets, from Paul Moore.
This patch changes the policy to use the netmsg initial SID as the "base"
SID/context for NetLabel packets which only have MLS security attributes.
Currently we use the unlabeled initial SID which makes it very difficult to
distinquish between actual unlabeled packets and those packets which have MLS
security attributes.
Specifically:
- polmatch need no longer make an exception for unlabeled_t
since a flow will now always match SPD rules with no contexts (per
the IPSec leak fix patch upstreamed a few weeks back), as
opposed to needing polmatch access to unlabeled_t.
Signed-off-by: Venkat Yekkirala <vyekkirala@TrustedCS.com>
> We could add another 'or' on the above constraint:
>
> or ( (t2 == mlsfilewrite_in_range) and (l1 dom l2) and (h1 domby h2) )
>
> I believe that would be the constraint you were looking for. I don't
> like the name of that attribute, but I couldn't come up with a better
> one off the top of my head. :)
>
Attached is a patch which I've tested against selinux-policy-2.4.2-1
that implements this additional constraint. The name is still a bit
forced, but it works.
-matt <mra at hp dot com>
* fix userdom_search_all_users_home_content() to use search_dir_perms;
* change ssh daemon macro to use userdom_search_all_users_home_dirs() instead of _home_content()
a xfrm policy. It also defines MLS policy for association { sendto,
recvfrom, polmatch }.
NOTE: When an inbound packet is not using an IPSec SA, a check is performed
between the socket label and the unlabeled sid (SYSTEM_HIGH MLS label). For
MLS purposes however, the target of the check should be the MLS label taken
from the node sid (or secmark in the new secmark world). This would present
a severe performance overhead (to make a new sid based on the unlabeled sid
with the MLS taken from the node sid or secmark and then using this sid as
the target). Pending reconciliation of the netlabel, ipsec and iptables contexts,
I have chosen to currently make an exception for unlabeled_t SAs if TE policy
allowed it. A similar problem exists for the outbound case and it has been similarly
handled in the policy below (by making an exception for unlabeled_t).
I am submitting the below limited patch pending a comprehensive patch from
Joy Latten at IBM (latten@austin.ibm.com).
I am not sure if I needed to manually do a "make tolib" in the flask subdir
and submit the results as well. Please let me know if I needed to.
Signed-off-by: Venkat Yekkirala <vyekkirala@TrustedCS.com>
