On Fri, 2004-06-04 at 08:15, Igor Borisovsky wrote:
Hi. I have a question about selinux policy configuration for FC2. I need to forbid access to the postgresql data files from user root. I guess i have to create certain type for postgresql. Let's name this type pgsql. Thus i have something like that: [root selinux pgsql]# pwd /var/lib/pgsql [root selinux pgsql]# ls -aZ drwx------+ postgres postgres postgres:object_r:pgsql_home_dir_t . drwxr-xr-x root root system_u:object_r:var_lib_t .. drwx------ postgres postgres postgres:object_r:pgsql_home_dir_t backups -rw------- postgres postgres postgres:object_r:pgsql_home_t .bash_history -rw-r--r-- postgres postgres postgres:object_r:pgsql_home_t .bash_profile drwx------ postgres postgres postgres:object_r:pgsql_home_dir_t data -rw-r--r-- postgres postgres postgres:object_r:pgsql_home_t initdb.i18n drwxr-xr-x+ postgres postgres postgres:object_r:pgsql_home_t .mc [root selinux pgsql]# So far user root within sysadm_r role has access to the postgresql data files. I guess i need to find and revoke this permission from sysadm_r role. After looking at the policy.conf file I can't understand this. So how can i prevent access to postgresql data files from user root? Thanks.
Russell Coker already responded to your posting on the fedora-selinux-list. I would only add a few comments:
1) If you truly want to start reducing the power of sysadm_t, then you would start by disabling the unrestricted_admin and unlimitedServices tunables in policy/tunable.te and make load. Otherwise, sysadm_t is completely unconfined in the Fedora policy. Then you can remove direct access by sysadm_t to your new types just by omitting the sysadmfile attribute from the type declarations for your new types. But as Russell noted, sysadm_t can easily get around such restrictions, so much more work would be necessary to truly prevent access.
2) If you just want to prevent root from having such access, you could remove sysadm_r from the authorized roles for root, as Russell noted. I think that for SELinux play machines, people have authorized root for only user_r and then authorized another user identity for staff_r and sysadm_r. But in Fedora, I think you would also have to remove pam_selinux from the /etc/pam.d/su configuration to achieve this goal, so that your non-root user can su to uid 0 without having his SELinux user identity changed to root. Otherwise, su will try to change the SELinux user identity to root at the same time.
3) Do you really want to prevent someone with the root password from having access to the database, or do you just want to prevent uid 0 processes from having access? A uid 0 process does not necessarily have the SELinux root user identity; the SELinux user identity is only assigned by particular programs such as login and sshd and is unaffected by setuid programs.
Thanks for reply. Let me explain in more details my problem. I have the database server under RedHat9. The postgresql database contains very important secure data. So nobody should have access to this data directly. Only authorized clients via SSL connections should have access. In the ordinary linux user root can steal postgresql data files or edit pg_hba.conf file to give access to itself. Thus I want to use FC2 to control access to data files for user root. User root should be only linux server administrator. For example, root should be able to create/delete user, install software/hardware, start/stop services. But root must not have access to postgresql files.
-----Original Message----- From: Stephen Smalley [mailto:sds@epoch.ncsc.mil] Sent: Friday, June 04, 2004 4:42 PM To: Igor Borisovsky Cc: SELinux@tycho.nsa.gov; Russell Coker; fedora-selinux-list@redhat.com Subject: Re: Access to the postgresql data files
On Fri, 2004-06-04 at 08:15, Igor Borisovsky wrote:
Hi. I have a question about selinux policy configuration for FC2. I need to forbid access to the postgresql data files from user root. I guess i have to create certain type for postgresql. Let's name this type pgsql. Thus i have something like that: [root selinux pgsql]# pwd /var/lib/pgsql [root selinux pgsql]# ls -aZ drwx------+ postgres postgres postgres:object_r:pgsql_home_dir_t . drwxr-xr-x root root system_u:object_r:var_lib_t .. drwx------ postgres postgres postgres:object_r:pgsql_home_dir_t backups -rw------- postgres postgres postgres:object_r:pgsql_home_t
.bash_history
-rw-r--r-- postgres postgres postgres:object_r:pgsql_home_t
.bash_profile
drwx------ postgres postgres postgres:object_r:pgsql_home_dir_t data -rw-r--r-- postgres postgres postgres:object_r:pgsql_home_t initdb.i18n drwxr-xr-x+ postgres postgres postgres:object_r:pgsql_home_t .mc [root selinux pgsql]# So far user root within sysadm_r role has access to the postgresql data files. I guess i need to find and revoke this permission from sysadm_r role. After looking at the policy.conf file I can't understand this. So how can i prevent access to postgresql data files from user root? Thanks.
Russell Coker already responded to your posting on the fedora-selinux-list. I would only add a few comments:
1) If you truly want to start reducing the power of sysadm_t, then you would start by disabling the unrestricted_admin and unlimitedServices tunables in policy/tunable.te and make load. Otherwise, sysadm_t is completely unconfined in the Fedora policy. Then you can remove direct access by sysadm_t to your new types just by omitting the sysadmfile attribute from the type declarations for your new types. But as Russell noted, sysadm_t can easily get around such restrictions, so much more work would be necessary to truly prevent access.
2) If you just want to prevent root from having such access, you could remove sysadm_r from the authorized roles for root, as Russell noted. I think that for SELinux play machines, people have authorized root for only user_r and then authorized another user identity for staff_r and sysadm_r. But in Fedora, I think you would also have to remove pam_selinux from the /etc/pam.d/su configuration to achieve this goal, so that your non-root user can su to uid 0 without having his SELinux user identity changed to root. Otherwise, su will try to change the SELinux user identity to root at the same time.
3) Do you really want to prevent someone with the root password from having access to the database, or do you just want to prevent uid 0 processes from having access? A uid 0 process does not necessarily have the SELinux root user identity; the SELinux user identity is only assigned by particular programs such as login and sshd and is unaffected by setuid programs.
-- Stephen Smalley sds@epoch.ncsc.mil National Security Agency
On Fri, 2004-06-04 at 10:59, Igor Borisovsky wrote:
Thanks for reply. Let me explain in more details my problem. I have the database server under RedHat9. The postgresql database contains very important secure data. So nobody should have access to this data directly. Only authorized clients via SSL connections should have access. In the ordinary linux user root can steal postgresql data files or edit pg_hba.conf file to give access to itself. Thus I want to use FC2 to control access to data files for user root. User root should be only linux server administrator. For example, root should be able to create/delete user, install software/hardware, start/stop services. But root must not have access to postgresql files.
You can use SELinux to ensure that only certain applications have direct access to the files. But if root can install software, then he can just replace those applications with his own code to get access to the files. Or he can replace any code or configuration on which those applications depend, e.g. the kernel, ld.so, whatever. And if there is any user account which is authorized to access those files and you let root manage user accounts, then root can gain access to those accounts. Not to mention issues of raw disk access, whether direct or indirect via filesystem administrative utilities. See the problem? So you would have to strip root of _many_ typical administrative privileges to truly enforce such a guarantee.
Ok. I see you. Can you explain me the following thing? As I understand in selinux all permissions must be explicitly granted. Hence there is permission to allow sysadm_t to enter the /var/lib/pgsql directory. I can't find something like this: allow sysadm_t pgsql_home_dir_t:dir {...}; It is interesting how sysadm_t type has access to /var/lib/pgsql directory? Thanks. -----Original Message----- From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov] On Behalf Of Stephen Smalley Sent: Friday, June 04, 2004 7:14 PM To: Igor Borisovsky Cc: SELinux@tycho.nsa.gov; 'Russell Coker'; fedora-selinux-list@redhat.com Subject: RE: Access to the postgresql data files
On Fri, 2004-06-04 at 10:59, Igor Borisovsky wrote:
Thanks for reply. Let me explain in more details my problem. I have the database server under RedHat9. The postgresql database contains very important secure data. So nobody should have access to this data directly. Only authorized clients via SSL connections should have access. In the ordinary linux user root can steal postgresql data files or edit pg_hba.conf file to give access to itself. Thus I want to use FC2 to control access to data files for user root. User root should be only linux server administrator. For example, root should be able to create/delete user, install software/hardware, start/stop services. But root must not have access to postgresql files.
You can use SELinux to ensure that only certain applications have direct access to the files. But if root can install software, then he can just replace those applications with his own code to get access to the files. Or he can replace any code or configuration on which those applications depend, e.g. the kernel, ld.so, whatever. And if there is any user account which is authorized to access those files and you let root manage user accounts, then root can gain access to those accounts. Not to mention issues of raw disk access, whether direct or indirect via filesystem administrative utilities. See the problem? So you would have to strip root of _many_ typical administrative privileges to truly enforce such a guarantee.
-- 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.
On Mon, 7 Jun 2004 17:35, "Igor Borisovsky" igor@datanaut.com wrote:
Ok. I see you. Can you explain me the following thing? As I understand in selinux all permissions must be explicitly granted. Hence there is permission to allow sysadm_t to enter the /var/lib/pgsql directory. I can't find something like this: allow sysadm_t pgsql_home_dir_t:dir {...}; It is interesting how sysadm_t type has access to /var/lib/pgsql directory?
The type pgsql_home_dir_t has attribute sysadmfile, which means sysadm_t gets full access. Remove the sysadmfile attribute and the access will be denied. But if the attribute is granted through the full_user_role() macro then it's probably easiest to just define a new type for this.
I used macro full_user_role() for pgsql type. Then I corrected policy.conf file manually. So definitions for the new types looks like this: type pgsql_home_dir_t, file_type, home_dir_type, home_type, user_home_dir_type, user_home_type; type pgsql_home_t, file_type, home_type, user_home_type; (I removed sysadmfile attribute) And finally I launched 'make load'. After that /var/lib/pgsql is still accessible for sysadm_t.
-----Original Message----- From: Russell Coker [mailto:russell@coker.com.au] Sent: Monday, June 07, 2004 12:23 PM To: fedora-selinux-list@redhat.com Cc: Igor Borisovsky; 'Stephen Smalley'; SELinux@tycho.nsa.gov Subject: Re: Access to the postgresql data files
On Mon, 7 Jun 2004 17:35, "Igor Borisovsky" igor@datanaut.com wrote:
Ok. I see you. Can you explain me the following thing? As I understand in selinux all permissions must be explicitly granted. Hence there is permission to allow sysadm_t to enter the /var/lib/pgsql directory. I can't find something like this: allow sysadm_t pgsql_home_dir_t:dir {...}; It is interesting how sysadm_t type has access to /var/lib/pgsql directory?
The type pgsql_home_dir_t has attribute sysadmfile, which means sysadm_t gets full access. Remove the sysadmfile attribute and the access will be denied. But if the attribute is granted through the full_user_role() macro then it's probably easiest to just define a new type for this.
On Mon, 2004-06-07 at 04:59, Igor Borisovsky wrote:
I used macro full_user_role() for pgsql type. Then I corrected policy.conf file manually. So definitions for the new types looks like this: type pgsql_home_dir_t, file_type, home_dir_type, home_type, user_home_dir_type, user_home_type; type pgsql_home_t, file_type, home_type, user_home_type; (I removed sysadmfile attribute) And finally I launched 'make load'. After that /var/lib/pgsql is still accessible for sysadm_t.
Did you also disable the unrestricted_admin and unlimitedServices tunables in tunable.te, as I said in my original reply?
To further elaborate on what Russell said, type attributes can be associated with types and then used in allow rules (or other rules) to apply a single rule to the set of all types with that attribute. Hence, simply grep'ing policy.conf isn't a reliable means of checking access. If you want to perform policy analysis, look at apol from the setools and setools-gui packages.
On Mon, 7 Jun 2004 18:59, "Igor Borisovsky" igor@datanaut.com wrote:
I used macro full_user_role() for pgsql type. Then I corrected policy.conf file manually. So definitions for the new types looks like this: type pgsql_home_dir_t, file_type, home_dir_type, home_type, user_home_dir_type, user_home_type;
sysadm_t has the privhome attribute which gives it full access to the home types through macros/user_macros.te .
Trying to edit this all by hand will be really painful, things aren't designed to work in that way and they won't work well. Defining a new type is really easy, requires no hand-modification of the generated policy.conf, and because it's the expected operation it's not going to break anything.
selinux@lists.fedoraproject.org
-
Igor Borisovsky -
Igor Borisovsky -
Russell Coker -
Stephen Smalley