All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel J Walsh <dwalsh@redhat.com>
To: Stephen Smalley <sds@epoch.ncsc.mil>
Cc: SELinux <SELinux@tycho.nsa.gov>
Subject: Re: Java Policy
Date: Fri, 04 Feb 2005 13:40:15 -0500	[thread overview]
Message-ID: <4203C18F.8030609@redhat.com> (raw)
In-Reply-To: <1107538571.8078.98.camel@moss-spartans.epoch.ncsc.mil>

Stephen Smalley wrote:

>On Fri, 2005-02-04 at 12:26, Daniel J Walsh wrote:
>  
>
>>This is policy for the java plugin.
>>Do not know if we want user apps that run java to transition.
>>
>>Will be sending in a big diff later today, but wanted input sooner.
>>    
>>
>
>- Neither I nor Tim Fraser wrote this java policy ;)  Looks like there
>is also cruft leftover from the netscape/mozilla policy in there.
>  
>
Ok, cleaned up comments. 

>- Might want to make it a general legacy_binary_t domain for use not
>only by java but by other legacy binaries.
>
>  
>
Well I don't think of this policy as a legacy binary  (Not that I would 
know what that means, I don't think
of Java as being legacy).  My goal was to create something for the java 
plugin not the java runtime.  Java
Runtime needs to have full access to the users environment since it is 
really the same as a scripting language
or any other executable.  We may want to write some policy but I feel 
you would need to duplicate the
base_users_domain to get it done.  Maybe this domain should be renamed 
javavm or  javaplugin.

>- I think there should also be a transition from the user domains on
>these legacy programs, so that they can be separately confined.
>
>  
>
Again not for this domain.

>- Not clear that you need to use a boolean in this domain, as the entire
>purpose of it is to deal with binaries that need this access.  Unless we
>can turn it off for other architectures.  But if you are going to use a
>boolean, we definitely want a separate one so that we can allow it to
>these legacy binaries without allowing it to the base user domains.
>  
>
I don't know if I agree with that.  I know people who say they refuse to 
run any code that allows
execmem/execmod.  If you don't have the global boolean you could 
accidently run them.



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

  reply	other threads:[~2005-02-04 18:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-04 17:26 Java Policy Daniel J Walsh
2005-02-04 17:36 ` Stephen Smalley
2005-02-04 18:40   ` Daniel J Walsh [this message]
2005-02-04 18:58     ` Stephen Smalley
2005-02-04 19:15       ` Daniel J Walsh
2005-02-04 18:02 ` Ivan Gyurdiev

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=4203C18F.8030609@redhat.com \
    --to=dwalsh@redhat.com \
    --cc=SELinux@tycho.nsa.gov \
    --cc=sds@epoch.ncsc.mil \
    /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.