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.From: Stephen Smalley <sds_at_tislabs.com>
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.From: Paul Krumviede <pwk_at_acm.org>
--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.From: Stephen Smalley <sds_at_tislabs.com>
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.
This archive was generated by hypermail 2.2.0 on Wed 11 Jun 2008 - 08:10:54 EDT