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@xxxxxxxxxxxxx>
>
> > 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@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/selinux
Attachment:
pgp6Oh2dl6OE0.pgp
Description: PGP signature
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
