Security Enhanced Linux
What's New
Frequently Asked Questions
Background
Documents
License
Download
Participating
Mail List
Archives
Remaining Work
Contributors
Related Work
Press Releases
Information Assurance Research
NIARL In-house Research Areas
Mathematical Sciences Program
Sabbaticals
Computer & Information Sciences Research
Technology Transfer
Advanced Computing
Advanced Mathematics
Communications & Networking
Information Processing
Microelectronics
Other Technologies
Technology Fact Sheets
Publications
Related Links
|
SELinux Mailing List
subject: (no subject) Date: Thu, 29 Aug 2002 11:48:40 -0400
The application is called HTTPServer (compiled from serv.c which is joined to this message). This application is located in /bin. A type for the file of the executable as been created (HTTPServer.fc located in policy/file_contexts/program/ and joined to this message). A type (domain) for the process as also been created (HTTPServer.te located in policy/domains/program also joined to this message). When using the sysadm_r role, starting HTTPServer, and checking the process with ps --context, the domain of the process is "HTTPServer_t". So everything looks normal. But when using the user_r role, starting HTTPServer, and checking the process with ps --context, the domain of the process is "user_t". The goal was to allow the execution of HTTPServer to the sysadm_r and not to user_r. A couple of things (e.g. commenting transition rules) to block the transition from HTTPServer_t to user_t, were tried without success. Would you have any helpful recommandation or ressource ? Thank you and regards, Eric Gingras Eric.Gingras@ericsson.ca
-- 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.From: Russell Coker <russell_at_coker.com.au> subject: (no subject) Date: Thu, 29 Aug 2002 18:21:59 +0200
The HTTPServer_t domain is not permitted in the user_r role. There is only a domain_auto_trans rule for starting from sysadm_t not from user_t. Also for a system daemon you should put it in role system_r, and have the domain_auto_trans rule define a transition from initrc_t (or just use the daemon_domain macro). Look at slapd.te or the latest named.te for an example of how to setup a daemon properly. Also such a daemon then needs a start script in the /etc/init.d directory and has to be started by run_init.
> The goal was to allow the execution of HTTPServer to the sysadm_r and not The macro in macros/user_macros.te calls can_exec_any() from macros/global_macros.te which allows it to execute any file type with the attribute exec_type. Remove exec_type from the type declaration for HTTPServer_exec_t and the user won't be able to execute it. Russell Coker PS It's not really a LSM issue. -- 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.From: david caplan <dac_at_tresys.com> subject: RE: Date: Thu, 29 Aug 2002 13:32:25 -0400
Narrowing down the permissions of the server domain also limits an attacker, who finds a vulnerability in your server code (e.g., a buffer overflow), to only the capabilities you have given that domain (i.e., even though the server might have been started by root it still couldn't read the password file or run a shell because it is now in the more limited HTTPServer_t domain). Like Russell suggested below, look at how other daemons have been setup and you'll get a good idea of what needs to be done. David
> -----Original Message----- -- 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.From: Stephen Smalley <sds_at_tislabs.com> subject: Re: (no subject) Date: Thu, 29 Aug 2002 14:15:32 -0400 (EDT)
On Thu, 29 Aug 2002, Eric Gingras (LMC) wrote:
> I'm quite a newbie to SELinux. Up to now, I've install the system and I've I'd suggest that you send questions regarding SELinux only to the selinux mailing list, not to the LSM mailing list. The LSM list is for discussion of the LSM kernel patch, not for module-specific discussions. I've dropped the LSM list from my reply. As you may have already noticed, there is a httpd_t domain in the example policy configuration that was written by MITRE for the Apache web server. See selinux/policy/domains/program/apache.te. However, it has not been converted over to using some of the newer macros like daemon_domain, so you might want to also look at some other daemon domains in the example policy like named.te.
> When using the sysadm_r role, starting HTTPServer, and checking the process Based on your .te file, this is correct. You do not define a domain transition from user_t or authorize the user_r role, so the process remains in user_r:user_t. User domains are given the ability to execute most programs by the example policy via the can_exec_any() macro. Limiting what a user domain can execute won't do much good unless you are also preventing the user from compiling their own programs, downloading programs from elsewhere, etc. As David Caplan explained, it doesn't matter whether an ordinary user can run the program, as long as the user doesn't gain any particular permissions by doing so (and this doesn't happen, since the domain is left unchanged). Please also note that you should authorize system_r for a daemon domain and define a domain transition from initrc_t if you want to start your daemon during system initialization. You can then remove direct authorization for sysadm_r and the domain transition from sysadm_t, instead using run_init to start the daemon by hand if necesssary. I'll assume that you have already read the Configuring the SELinux Policy report provided in the release and available from the NSA SELinux web site. If not, RTM. -- Stephen D. Smalley, NAI Labs ssmalley@nai.com -- 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.
|
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |