[prev in list] [next in list] [prev in thread] [next in thread] 

List:       selinux
Subject:    RE: Object class and permissions documentation
From:       "Karl MacMillan" <kmacmillan () tresys ! com>
Date:       2004-04-22 19:23:55
Message-ID: 200404221923.i3MJNOJx026838 () gotham ! columbia ! tresys ! com
[Download RAW message or body]

Steve,

Thanks for all of the comments - this is the type of discussion that we were
hoping to generate by posting this.

Karl

Karl MacMillan
Tresys Technology
http://www.tresys.com
(410)290-1411 ext 134 

> -----Original Message-----
> From: Stephen Smalley [mailto:sds@epoch.ncsc.mil]
> Sent: Thursday, April 22, 2004 2:56 PM
> To: Karl MacMillan
> Cc: 'SELinux'; 'Selinux Dev'; James Morris
> Subject: Re: Object class and permissions documentation
> 
> On Thu, 2004-04-22 at 13:48, Karl MacMillan wrote:
> > We are posting this in the hopes that it might be useful, but please
> note
> > that the permission descriptions are only a rough initial version and
> might
> > be incomplete or inaccurate. Please send any updates or suggestions for
> > changes to these descriptions, or any other part of this document, to
> selinux@tresys.com.
> 
> Thanks for working on this document, as an up-to-date document
> describing the classes, permissions, and permission checks per operation
> would be useful.  Note that the original technical report had such
> tables for the original implementation, and the module report had the
> permission check tables for the LSM hooks in the earlier LSM-based
> SELinux.  Some comments below:
> 
> - No point in repeating common permissions for each class; describe once
> and note inheritance.
> 
> - Class and permission lists should be grouped logically where
> appropriate (e.g. all file-related classes together, read/write/execute
> together, setattr/getattr together).
> 
> - It would help understanding to list the pair of entities involved in
> each permission check, e.g. ptrace - Control ability of a process to
> ptrace a given target process.  udp_recv - Control ability of a socket
> to receive UDP packets from a given network interface.
> 
> - Class file has two additional permissions beyond the common set.
> 
> - Some permissions are included in common sets merely to be available
> in more than one class, but are not actually applicable to all classes
> that inherit (a more general inheritance mechanism would be useful). So
> you may want to note permissions that are actually not valid for a given
> class and should not be granted.
> 
> - The redesign/reimplementation of the network access controls in 2.6
> caused changes to the semantics of some of the existing socket and
> network permissions, not just the addition of new permissions.
> Examples:
> -- send_msg/recv_msg were formerly a socket-to-packet check for labeled
> networking, and irrelevant in the absence of labeled networking.  The
> permission names were reclaimed for use by the new socket-to-port checks
> in 2.6.  Correspondingly, the SID equality check is gone.
> - sendto/recvfrom were formerly a socket-to-peer-socket check for
> labeled networking, and irrelevant in the absence of labeled
> networking.  They are not used at all presently for INET sockets.
> sendto is still used for Unix datagram sockets for the
> socket-to-peer-socket check.  recvfrom is presently unused; we could
> certainly implement it for Unix datagram, but it becomes redundant with
> sendto as the IPC is local.
> - netif recv checks were formerly packet-to-netif (can this packet be
> received on this netif?) for labeled networking, and irrelevant in the
> absence of labeled networking.  The checks were changed to
> socket-to-netif (i.e. can this socket receive from this netif?) in 2.6.
> netif send checks were formerly packet-to-netif (can this packet be
> sent on this netif?) and are now socket-to-netif (can this socket send
> on this netif?) but that change is mostly invisible as outbound packets
> were inheriting their SID from the sending socket by default anyway.
> - connectto/newconn/acceptfrom were formerly socket-to-peer-socket or
> socket-to-newconnectionsocket checks.  They are not presently used for
> INET sockets.  connectto is still used for Unix stream sockets.
> acceptfrom and newconn are unused.
> - enforce_dest is presently unused; had to do with the extended socket
> call API in the older SELinux.
> - node_bind controls the binding to an IPv4 or IPv6 address
> (socket-to-node).
> 
> - Class passwd permissions have to do with skipping authentication, e.g.
> set another user's password or other information without having to know
> the user's old password, su'ing to an account without needing the
> password, etc.  Not just updating of state.
> 
> - Class dir permission reparent - might want to note that the
> reparenting of the directory occurs via rename for clarity.
> 
> - Class security permissions - they aren't used to set information
> (other than load, setenforce, setbool); they are used to get security
> decisions.  selinuxfs exports the old policy API; the process writes the
> policy query to the node, and then reads back the response, using a
> file-local buffer.
> 
> - System V IPC classes - unix_read and unix_write are coarse-grained
> permissions that parallel the existing Linux checks.  See the module
> report's discussion of changes from the original SELinux kernel patch.
> 
> - A number of the system permissions you list are not present in the
> current policy (and the number is wrong).
> 
> - Note that fifo_file is used for both fifos in the filesystem and
> pipes.  Pipes are labeled with the context of the creating process,
> whereas the fifos in the filesystem have a file context.
> 
> - Don't confuse sock_file and sockets.  Different objects (inodes) with
> different labels, but associated with one another.  Connecting to a Unix
> stream socket requires write permission to the file object and connectto
> permission to the socket object.
> 
> - noatsecure disables the default AT_SECURE flag on a context change, so
> that glibc secure mode is not enabled in that case and the caller can
> influence the new context.  Useful for trusted callers that expect to be
> able to set up the environment or other characteristics of the callee.
> 
> - Class process permission getattr isn't about file attributes.
> 
> - setexec controls ability to exec context at all.  Other permissions
> (transition, entrypoint, etc) control the particular context that may
> be used for a given exec.
> 
> --
> Stephen Smalley <sds@epoch.ncsc.mil>
> National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
[prev in list] [next in list] [prev in thread] [next in thread]