All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel J Walsh <dwalsh@redhat.com>
To: SE Linux <selinux@tycho.nsa.gov>
Subject: Re: I think this is a bug in the kernel
Date: Fri, 09 May 2008 10:16:54 -0400	[thread overview]
Message-ID: <48245CD6.2060206@redhat.com> (raw)
In-Reply-To: <4824560E.8060500@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel J Walsh wrote:
| https://bugzilla.redhat.com/show_bug.cgi?id=445709
|
| libvirtd is clearly not ptracing the unconfined_t domain.  It is
| problably looking under /proc for some information about the app that is
| communicating with it.  It might be reading unconfined_t environment.  I
| am not sure, but we generate a ptrace and stop the app from working.  My
| only choice is to allow virtd to ptrace unconfined_t processes which is
| not a good idea.  This has to be fixes in the kernel.
|
| Dan

- --
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.

Replying to my own email...

Looks like the kernel has it on its todo list...

~ *  Finer-grained proc checking (so that we don't require full ptrace
permission just to read process state),

Well I think we need to jump the priority here.

User apps seem to be doing things like looking at the remote end of the
socket and checking the environment for special cookies in the case of
consolehelper/policykit.  Or may looking to see where the kerberos
tickets are located.  Whether this is a legitimate use or not, it is
being done.  So we need to handle it.  But I have a real concern about
allowing virtd_t to ptrace unconfined_t process.

Basically in order to allow virtd_t to verify the unconfined_t process
that is trying to communicate with it, we need to allow it to read the
memory of every unconfined_t process on the system.  Not good.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkgkXNYACgkQrlYvE4MpobOC4ACcChtet42S8Y7ffL0l82Eb4FDM
zJEAn2Kxb9sx2SXP87kTUMvbiIurarH8
=3qY6
-----END PGP SIGNATURE-----

--
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.

  parent reply	other threads:[~2008-05-09 14:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-09 13:47 I think this is a bug in the kernel Daniel J Walsh
2008-05-09 14:14 ` Stephen Smalley
2008-05-09 14:16 ` Daniel J Walsh [this message]
2008-05-09 14:25   ` Stephen Smalley
2008-05-09 14:30     ` Daniel J Walsh
2008-05-09 14:34       ` Stephen Smalley
2008-05-09 14:42         ` Daniel J Walsh
2008-05-09 14:53           ` Stephen Smalley
2008-05-09 15:03             ` Daniel J Walsh
2008-05-12 12:26 ` Daniel J Walsh
2008-05-12 13:08   ` Stephen Smalley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48245CD6.2060206@redhat.com \
    --to=dwalsh@redhat.com \
    --cc=selinux@tycho.nsa.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.