3:10 p.m.
I'm trying to set up F17 SELinux to accept the Swedish electronic
identity system called "BankID". I had it working under F16 with only
a few file context specifications for its libraries. (They need
textrel_shlib_t). But it seems like the policy has been tightened up
a bit in F17, which made some more tunings necessary. And I fail on
one of them.
This thing runs as a browser plugin, which starts a program, and
creates a few files in the user's home directory. My question is how
to define the context for these files. BankID creates a file called
".personal-<username>" and a directory tree ".personal/...". I
added
a file context like this with semanage:
/home/[^/]*/\.personal.* all files system_u:object_r:mozilla_home_t:s0
After relabeling things in the .personal tree gets the mozilla_home_t,
but the file .personal-<username> directly in the home directory
doesn't. If it exists, it gets the right context when I do
restorecon. But it is created and removed each time the plugin is
run, and the next time the file is created, it gets user_home_dir_t.
Which the plugin in the mozilla_plugin_t context isn't allowed to
access, of course.
What am I doing wrong?
3:45 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/27/2012 04:10 PM, goeran(a)uddeborg.se wrote:
I'm trying to set up F17 SELinux to accept the Swedish electronic
identity
system called "BankID". I had it working under F16 with only a few file
context specifications for its libraries. (They need textrel_shlib_t).
But it seems like the policy has been tightened up a bit in F17, which made
some more tunings necessary. And I fail on one of them.
This thing runs as a browser plugin, which starts a program, and creates a
few files in the user's home directory. My question is how to define the
context for these files. BankID creates a file called
".personal-<username>" and a directory tree ".personal/...". I
added a
file context like this with semanage:
/home/[^/]*/\.personal.* all files
system_u:object_r:mozilla_home_t:s0
After relabeling things in the .personal tree gets the mozilla_home_t, but
the file .personal-<username> directly in the home directory doesn't. If
it exists, it gets the right context when I do restorecon. But it is
created and removed each time the plugin is run, and the next time the file
is created, it gets user_home_dir_t. Which the plugin in the
mozilla_plugin_t context isn't allowed to access, of course.
What am I doing wrong?
-- selinux mailing list selinux(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
Can you get .personal-username into the .personal directory?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+bBX8ACgkQrlYvE4MpobMJhwCffx6MsUWlL5a4K2PJTnq9v8EK
NIsAoMta+36PoL+iW/7n+P8KIRHkyw45
=rS4l
-----END PGP SIGNATURE-----
10:19 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/27/2012 05:23 PM, goeran(a)uddeborg.se wrote:
Daniel J Walsh:
> Can you get .personal-username into the .personal directory?
Not in any obvious way. It's a closed source program (started from
firefox) which creates and removes it.
Ok we would have to write custom policy for
this then.
We can write fairly tight policy for a fixed name being created within the
homedir, In this case we have to allow mozilla-plugin to create any file in
the homedir if it does not exist and label it mozilla_home_t. Which means a
plugin could create .bashrc for example, if it did not exist.
I am adding a boolean mozilla_plugin_enable_homedirs to control whether or not
mozilla/firefox plugins can create random content file/directories in the
users homedir. (Disabled by default).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+erY4ACgkQrlYvE4MpobMcZACfacOaCroUXtjo05fZpJZY8yLr
J78AnAinaety84CbtePHOSGb7j5idkUd
=ax0E
-----END PGP SIGNATURE-----
3:49 p.m.
Daniel J Walsh:
In this case we have to allow mozilla-plugin to create any file in
the homedir if it does not exist and label it mozilla_home_t.
Ouch! I had hoped something like the regular expressions of "semanage
fcontext" could have done it simpler.
Hm. I wonder if there might be a better way. In the case of BankID
the plugin starts a separate binary that does some of the work. I
believe, in particular, it's that binary that creates the problematic
file.
Maybe I could write a policy module that puts this binary in a
specific domain when started from mozilla_plugin_t. I would have to
let that domain create files in the home directory, but I wouldn't
have to let ALL plugins do it. It would be a bit better.
I'll give it a try. It will be a much more advanced module than I've
done before.
9:49 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/30/2012 04:49 PM, goeran(a)uddeborg.se wrote:
Daniel J Walsh:
> In this case we have to allow mozilla-plugin to create any file in the
> homedir if it does not exist and label it mozilla_home_t.
Ouch! I had hoped something like the regular expressions of "semanage
fcontext" could have done it simpler.
Hm. I wonder if there might be a better way. In the case of BankID the
plugin starts a separate binary that does some of the work. I believe, in
particular, it's that binary that creates the problematic file.
Maybe I could write a policy module that puts this binary in a specific
domain when started from mozilla_plugin_t. I would have to let that domain
create files in the home directory, but I wouldn't have to let ALL plugins
do it. It would be a bit better.
I'll give it a try. It will be a much more advanced module than I've done
before.
Go for it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+f9/sACgkQrlYvE4MpobOmeACgw0cuP/mn9W7y4Szsd/gUzEZ1
xqUAoKSm5tsIxeCbogwv1FrH/YZ5kRsV
=NRYk
-----END PGP SIGNATURE-----
4385
days inactive
4389
days old
selinux@lists.fedoraproject.org
5 comments
2 participants
participants (2)
-
Daniel J Walsh -
Göran Uddeborg