Two diferent Java programs on same machine

[giovanni testing]

I just only want to give permissions for the files that are used. The java
application is a server that might be compromised, so if an attacker gains
permissions to run arbitrary code, or to read arbitrary files, the  usr_t
type files can provide information about the system, so I think that it is
not recommendable grant access to all usr_t type files.

2010/7/15 Dominick Grift <domg472 at gmail.com>

> On Thu, Jul 15, 2010 at 12:10:18PM +0200, giovanni testing wrote:
> > Hi,
> >
> > I've fixed it (thanks to "/sbin/ausearch -i | grep nano | grep avc"), and
> > the allow lines needed are:
> >
> > allow MyPolicy_t bin_t:file entrypoint;
> > allow MyPolicy_t usr_t:file { read open };
>
> corecmd_bin_entry_type(MyPolicy_t)
> files_read_usr_files(MyPolicy_t)
>
> >
> > I think that the second one is not appropiated, because MyPolicy now can
> > access to every "usr_t" file (but is only needed to access to
> > "/usr/share/terminfo/x/xterm").
>
> What is the problem with it? Do you have any special reason for now wanting
> to allow it to read usr_t files?
>
> > To fix that, I'm thinking in a solution that I don't know if is possible:
> > label the file "/usr/share/terminfo/x/xterm" with "xterm_t" instead of
> > "usr_t", but maybe it can block other applications to use
> > "/usr/share/terminfo/x/xterm", so the "xterm_t" needs to be equivalent to
> > "usr_t". To do it I'm thinking to use an alias, but if is bidirectional
> it
> > will be insecure again. As these lines can seem a bit confusing, there is
> a
> > little scheme:
> >
> > I need:
> > - "MyPolicy_t" can use "xterm_t"
> > - "MyPolicy_t" cannot "usr_t"
> > - Other policies continue being able to use "/usr/share/terminfo/x/xterm"
> > while they allow use "usr_t" and they have not specified to allow
> "xterm_t".
> >
> > So accessing to "usr_t" needs to be able to access to "xterm_t", but
> > accessing to "xterm_t" not needs to be able to access to "usr_t" (this is
> > what I say that it not needs to be bidirectional). Maybe it can be done
> that
> > way (putting the following lines instead the two before):
> >
> > allow MyPolicy_t bin_t:file entrypoint;
> > allow usr_t xterm_t:file manage_file_perms;
> > allow MyPolicy_t xterm_t:file { read open };
>
> usr_t is a file type. file_types cannot be a source of an interacting.
>
> Again, what security benefit does labeling /usr/share/terminfo/x/xterm type
> xterm_t provide? What is so important that you do not want MyPolicy_t to be
> able to read files with type etc_t?
>
> If you really want to do it then just label it that type and give
> everything that needs to be able to interact with it the permissions they
> need.
>
> > 2010/7/14 Stephen Smalley <sds at tycho.nsa.gov>
> >
> > > On Wed, 2010-07-14 at 17:47 +0200, giovanni testing wrote:
> > > > Thank you for reply so fast.
> > > >
> > > > I'm trying runcon but throws "Permission denied" and no AVC appears
> (I
> > > > dont know how to fix it).
> > > >
> > > > This happens when applying the command "runcon -t MyPolicy_t
> > > > nano" (nano is executed to make easier the task of probe the file
> > > > permissions of the policy (try to open files of MyPolicy and verify
> > > > that they are read only, read and write or no accessible)).
> > > >
> > > > What should I do to fix it?
> > >
> > > Post your .te file.
> > > Also, run:
> > > /sbin/ausearch -i | grep nano
> > >
> > > --
> > > Stephen Smalley
> > > National Security Agency
> > >
> > >
>
> > --
> > selinux mailing list
> > selinux at lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/selinux
>
>
> --
> selinux mailing list
> selinux at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/selinux/attachments/20100715/36645ff5/attachment.html