applications and ports

applications and ports

[Lonnie Cumberland]

Hello All,

I was just wondering about the way to take full advantage of the
security features of SELinux.

If I add a new application to my system or a new service to my
xinet.d services then in order for SELinux to impose the security
policy on it I would guess that I have to make a TE file for it and
rerun the make, right?

Would this also mean that there are applications and service that
might not be under the SELinux security policy that exist on my
machine and that could potentially cause problems?

Cheers,
Lonnie

-- 
 Lonnie Cumberland
 OutStep Technologies Incorporated
 (313) 832-7366

 URL: http://www.outstep.com
 EMAIL: Lonnie@OutStep.com
      : Lonnie_Cumberland@yahoo.com




--
You have received this message because you are subscribed to the selinux 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.

Re: applications and ports

[Stephen Smalley]

On Tue, 29 Jan 2002, Lonnie Cumberland wrote:

> If I add a new application to my system or a new service to my
> xinet.d services then in order for SELinux to impose the security
> policy on it I would guess that I have to make a TE file for it and
> rerun the make, right?
>
> Would this also mean that there are applications and service that
> might not be under the SELinux security policy that exist on my
> machine and that could potentially cause problems?

Every process is controlled by the SELinux security policy.  However, if
you allow a domain to execute a program type and you do not specify a
domain transition for that (domain, type) pair, then the process will
remain in the original domain.  This can potentially result in the process
having more permissions than desired or in the process having too few
permissions to function.

Step 17 of the README discusses this issue for the daemons started by the
rc scripts.  For xinetd, there is an example domain for the xinetd daemon
(inetd_t in inetd.te) and some example domain transitions for some of the
programs run by it (e.g. tcpd, rlogind, rshd, ftpd).  All other
/usr/sbin/in\.*d programs are currently placed into the generic
inetd_child_t domain, but you can split out new domains for services
that you require.

For user applications (as opposed to system services), you only need to
assign a particular domain if the application should run with different
permissions than the user (e.g. newrole is run in a domain that has
greater permissions so that it can change roles, while netscape is run in
a more restricted domain so that it cannot tamper with the user's files
outside of a particular sandbox).

To add a new domain, you need to define the new domain in the policy
configuration (e.g. create a new .te file) and load it (via 'make load'
in the policy directory).  You also need to assign the program type
associated with the domain to the program in the file_contexts
configuration and run 'make relabel' in the setfiles directory.
Alternatively, you can directly set the label on a program via chcon, but
it is a good idea to also update the file_contexts configuration in case
you later do a 'make relabel'.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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.

file labeling (was Re: applications and ports)

[Paul Krumviede]

--On Tuesday, 29 January, 2002 10:32 -0500 Stephen Smalley 
<sds@tislabs.com> wrote:

> You also need to assign the program type
> associated with the domain to the program in the file_contexts
> configuration and run 'make relabel' in the setfiles directory.
> Alternatively, you can directly set the label on a program via chcon, but
> it is a good idea to also update the file_contexts configuration in case
> you later do a 'make relabel'.

i would emphasize this last sentence, as i've confused myself by
failing to track manually labeled files in file_contexts only to have
policy changes fail to work unexpectedly after i'd relabel the
file system.

as an aside, the default install for file-utils in the latest release
doesn't seem to install the chcon man page, so i didn't find
the option to not dereference symbolic links for a bit.

-paul


--
You have received this message because you are subscribed to the selinux 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.

Re: file labeling (was Re: applications and ports)

[Stephen Smalley]

On Tue, 29 Jan 2002, Paul Krumviede wrote:

> i would emphasize this last sentence, as i've confused myself by
> failing to track manually labeled files in file_contexts only to have
> policy changes fail to work unexpectedly after i'd relabel the
> file system.

It might be nice to have a tool that traverses the filesystem, compares
the file labels with the existing file_contexts configuration, and
generates an updated file_contexts based on the current state.  This could
be implemented as an option to the existing setfiles program.

At present, you could generate a complete mapping of the current state
using the modified ls or find programs, but that would lack the
conciseness and generality of the file_contexts configuration.


> as an aside, the default install for file-utils in the latest release
> doesn't seem to install the chcon man page, so i didn't find
> the option to not dereference symbolic links for a bit.

Sorry.  As a side note, the --help option often works.  Also, there are
the simple chsid and lchsid test programs.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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.