Hello, I am writing an application that I want to limit using selinux.
audit.log shows that it wants access to /etc/nsswitch.conf and /etc/hosts - which doesn't seem to unreasonable, however both these have types etc_t , and allowing myapp_t to read etc_t would also give it access to for example /etc/passwd, which i do not want.
Do I have to invent a new type for these two files to be able to keep my application from the other etc_t files in /etc ?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Torbjørn Lindahl wrote:
Hello, I am writing an application that I want to limit using selinux.
audit.log shows that it wants access to /etc/nsswitch.conf and /etc/hosts - which doesn't seem to unreasonable, however both these have types etc_t , and allowing myapp_t to read etc_t would also give it access to for example /etc/passwd, which i do not want.
Do I have to invent a new type for these two files to be able to keep my application from the other etc_t files in /etc ?
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Yes you can, but the more different file_context that you have in /etc, the harder they will be to maintain.
Reading /etc/passwd is not as dangerous as being able to read /etc/shadow. So consider if this is really necessary.
Good point. I probably can live with that.
Still I am not sure if I would like it to have full access to all files labelled etc_t . It would be nice to be able to single out only a few of them. Perhaps I should look at something other than the targeted policy.
On 9/17/07, Daniel J Walsh dwalsh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Torbjørn Lindahl wrote:
Hello, I am writing an application that I want to limit using selinux.
audit.log shows that it wants access to /etc/nsswitch.conf and
/etc/hosts -
which doesn't seem to unreasonable, however both these have types etc_t
,
and allowing myapp_t to read etc_t would also give it access to for
example
/etc/passwd, which i do not want.
Do I have to invent a new type for these two files to be able to keep my application from the other etc_t files in /etc ?
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Yes you can, but the more different file_context that you have in /etc, the harder they will be to maintain.
Reading /etc/passwd is not as dangerous as being able to read /etc/shadow. So consider if this is really necessary. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFG7uxvrlYvE4MpobMRAk+5AJ9UZPJZq++LfpMZMRyF62bvWCOTqQCgsdly +DO1I81MDsGkD0L3p3RiV/4= =WV5q -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Torbjørn Lindahl wrote:
Good point. I probably can live with that.
Still I am not sure if I would like it to have full access to all files labelled etc_t . It would be nice to be able to single out only a few of them. Perhaps I should look at something other than the targeted policy.
On 9/17/07, Daniel J Walsh dwalsh@redhat.com wrote: Torbjørn Lindahl wrote:
Hello, I am writing an application that I want to limit using selinux.
audit.log shows that it wants access to /etc/nsswitch.conf and
/etc/hosts -
which doesn't seem to unreasonable, however both these have types etc_t
,
and allowing myapp_t to read etc_t would also give it access to for
example
/etc/passwd, which i do not want.
Do I have to invent a new type for these two files to be able to keep my application from the other etc_t files in /etc ?
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Yes you can, but the more different file_context that you have in /etc, the harder they will be to maintain.
Reading /etc/passwd is not as dangerous as being able to read /etc/shadow. So consider if this is really necessary.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
All of the current policies including mls allow reading of etc_t for most domains, and /etc/passwd is labeled etc_t.
I see. In that case I am not going to push this topic much further. Thanks for your assistance!
But wouldn't it be nice to have an allow mechanism in SELinux in which I could grant access based on it's existing access. What I want to achieve is to be able to add a rule like "If process can read etc_t, then it can also read etc_foo_t"
That would allow me to change context of individual files, and grant access to them by process who already have etc_t, and I wouldn't have to redefine almost the entire selinux context tree just to target a few individual files in /etc for my app.
T.
On 9/18/07, Daniel J Walsh dwalsh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Torbjørn Lindahl wrote:
Good point. I probably can live with that.
Still I am not sure if I would like it to have full access to all files labelled etc_t . It would be nice to be able to single out only a few of them. Perhaps I should look at something other than the targeted policy.
On 9/17/07, Daniel J Walsh dwalsh@redhat.com wrote: Torbjørn Lindahl wrote:
Hello, I am writing an application that I want to limit using
selinux.
audit.log shows that it wants access to /etc/nsswitch.conf and
/etc/hosts -
which doesn't seem to unreasonable, however both these have types
etc_t
,
and allowing myapp_t to read etc_t would also give it access to for
example
/etc/passwd, which i do not want.
Do I have to invent a new type for these two files to be able to keep
my
application from the other etc_t files in /etc ?
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Yes you can, but the more different file_context that you have in /etc, the harder they will be to maintain.
Reading /etc/passwd is not as dangerous as being able to read /etc/shadow. So consider if this is really necessary.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
All of the current policies including mls allow reading of etc_t for most domains, and /etc/passwd is labeled etc_t. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFG8AFbrlYvE4MpobMRAtxMAKCXrwFqgATmTBQoNip52wmaHXFowQCgj0Ld Jz2zh2M8ID/nkU4Rgod4UVw= =8+JV -----END PGP SIGNATURE-----
On Wed, 2007-09-19 at 11:09 +0200, Torbjørn Lindahl wrote:
I see. In that case I am not going to push this topic much further. Thanks for your assistance!
But wouldn't it be nice to have an allow mechanism in SELinux in which I could grant access based on it's existing access. What I want to achieve is to be able to add a rule like "If process can read etc_t, then it can also read etc_foo_t"
That would allow me to change context of individual files, and grant access to them by process who already have etc_t, and I wouldn't have to redefine almost the entire selinux context tree just to target a few individual files in /etc for my app.
A notion of type inheritance has been discussed previously on selinux list (the upstream list for general selinux discussion, as opposed to this list which is Fedora-specific), and has come up again recently. The devil of course is in the details...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Torbjørn Lindahl wrote:
I see. In that case I am not going to push this topic much further. Thanks for your assistance!
But wouldn't it be nice to have an allow mechanism in SELinux in which I could grant access based on it's existing access. What I want to achieve is to be able to add a rule like "If process can read etc_t, then it can also read etc_foo_t"
That would allow me to change context of individual files, and grant access to them by process who already have etc_t, and I wouldn't have to redefine almost the entire selinux context tree just to target a few individual files in /etc for my app.
T.
On 9/18/07, Daniel J Walsh dwalsh@redhat.com wrote: Torbjørn Lindahl wrote:
Good point. I probably can live with that.
Still I am not sure if I would like it to have full access to all files labelled etc_t . It would be nice to be able to single out only a few of them. Perhaps I should look at something other than the targeted policy.
On 9/17/07, Daniel J Walsh dwalsh@redhat.com wrote: Torbjørn Lindahl wrote:
> Hello, I am writing an application that I want to limit using
selinux.
> audit.log shows that it wants access to /etc/nsswitch.conf and
/etc/hosts -
> which doesn't seem to unreasonable, however both these have types
etc_t
,
> and allowing myapp_t to read etc_t would also give it access to for
example
> /etc/passwd, which i do not want. > > > Do I have to invent a new type for these two files to be able to keep
my
> application from the other etc_t files in /etc ? > > > > > >
> -- > fedora-selinux-list mailing list > fedora-selinux-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Yes you can, but the more different file_context that you have in /etc, the harder they will be to maintain.
Reading /etc/passwd is not as dangerous as being able to read /etc/shadow. So consider if this is really necessary.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
All of the current policies including mls allow reading of etc_t for most domains, and /etc/passwd is labeled etc_t.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
We could do something like this with attributes.
If you created an attribute of etc_filetype
Then gave etc_t this attribute, change the interfaces that say files_read_etc_files() to use the attribute instead of the file.
Now when you create new file types, you could define them as etc_filetype.
"DJW" == Daniel J Walsh dwalsh@redhat.com writes:
DJW> We could do something like this with attributes.
I wonder if this would help my situation with denyhosts. The problem with denyhosts is that it needs to write to /etc/hosts.deny, which means that from the standpoint of selinux it needs to write to etc_t, which means it gets to write to /etc/passwd as well. I've not bothered to even attempt to write a policy for denyhosts given that it would be mostly pointless if it would still get to trash /etc.
- J<
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jason L Tibbitts III wrote:
"DJW" == Daniel J Walsh dwalsh@redhat.com writes:
DJW> We could do something like this with attributes.
I wonder if this would help my situation with denyhosts. The problem with denyhosts is that it needs to write to /etc/hosts.deny, which means that from the standpoint of selinux it needs to write to etc_t, which means it gets to write to /etc/passwd as well. I've not bothered to even attempt to write a policy for denyhosts given that it would be mostly pointless if it would still get to trash /etc.
- J<
You would change the context of denyhosts to denyhosts_etc_rw_t and they write a rule saying
allpw denyhost_t denyhost_etc_rw_t:file manage_file_perms files_etc_filetrans(denyhost_t, denyhost_etc_rw_t; file)
This would allow denyhost_t to only write to files labeled denyhost_etc_rw_t, and be able to create files in /etc/ labeled denyhost_etc_rw_t. It will not allow you to write to files labeled etc_t, So you cannot overwrite /etc/passwd.
selinux@lists.fedoraproject.org