| 1 |
On Fri, 2006-02-03 at 09:58 +0100, Mivz wrote: |
| 2 |
> Mivz wrote: |
| 3 |
> > Chris PeBenito wrote: |
| 4 |
> >>>> plain text document attachment (heimdal-LDAP.te) |
| 5 |
> >>> |
| 6 |
> >>> #/tmp/krb5cc |
| 7 |
> >>> allow user_t local_login_tmp_t:file { read lock append }; |
| 8 |
> >>> |
| 9 |
> >> |
| 10 |
> > I added this rule because pam_krb5 init's the krbcc and thus causes |
| 11 |
> > the /tmp/krbcc to be in the wrong security context. Also kinit and |
| 12 |
> > kdestroy loose access to /tmp/krbcc because of this. Is this a |
| 13 |
> > pam_krb5 bug, because it creates the /tmp/krbcc file in the wrong |
| 14 |
> > context, or a selinux-kerberos bug, because it does not handel the |
| 15 |
> > /tmp/krbcc file correct? |
| 16 |
> |
| 17 |
> I had another thought about this. The krb5cc files are one of the most |
| 18 |
> important files for a kerberos client. It holds your identity. Loosing |
| 19 |
> this file is like loosing a part of your shadow file. So I think this |
| 20 |
> file should be highly protected. The current selinux-kerberos policy |
| 21 |
> does not do this. I think every user should have a separated selinux |
| 22 |
> context for his krb5cc file and each program needing access to this |
| 23 |
> should be specified in the selinux policy. |
| 24 |
> This would prevent miscellaneous software for reaching this file and |
| 25 |
> abusing your identity. |
| 26 |
> It would be something like user:object_r:krb5_cc_t. Al programs |
| 27 |
> accessing should have a file_type_auto_trans. |
| 28 |
> I would like to work on this, but I don't know if it has any use, |
| 29 |
> because of the new upcoming policy. |
| 30 |
|
| 31 |
You can look at the new policy [1] and compare, it is newer than the |
| 32 |
policy in portage. In the long run it would be better to develop that |
| 33 |
policy. |
| 34 |
|
| 35 |
> Is this policy just different being |
| 36 |
> modular and having to add dependency's like in the current |
| 37 |
> policy-server-policy, or are the basic macros and policy also going to |
| 38 |
> change that much that each policy has to be rewritten form scratch? |
| 39 |
|
| 40 |
Reference policy is indeed written from scratch, using the old example |
| 41 |
policy as a reference. |
| 42 |
|
| 43 |
> I also would like some comment on my idee for the krb5cc file. |
| 44 |
|
| 45 |
If each user gets a different file, then it would be better if there was |
| 46 |
a specific type for each role. If there is a single file, then it |
| 47 |
sounds like you're on the right track. So for a firm answer, we need to |
| 48 |
understand these questions, and also how the file is managed. |
| 49 |
|
| 50 |
[1] http://cvs.sourceforge.net/viewcvs.py/serefpolicy/refpolicy/policy/modules/services/kerberos.te?rev=1.16&view=auto |
| 51 |
|
| 52 |
-- |
| 53 |
Chris PeBenito |
| 54 |
<pebenito@g.o> |
| 55 |
Developer, |
| 56 |
Hardened Gentoo Linux |
| 57 |
Embedded Gentoo Linux |
| 58 |
|
| 59 |
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE6AF9243 |
| 60 |
Key fingerprint = B0E6 877A 883F A57A 8E6A CB00 BC8E E42D E6AF 9243 |
Archives