correct way to set context in perl?

correct way to set context in perl?

[Maria Iano]

What is a good way to set the security context for a new file created within a perl script? I have a perl script that creates new directories and zone files for my name server, and some are master and some slave. So when the script creates them it needs to set some to be of type named_zone_t and some to be of type named_cache_t. Should I just use the system call to chcon?

Thanks for any help.

Maria 

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

Re: correct way to set context in perl?

[Erich Schubert]

Hi,
I'd recommend to use different directories for master and slave zones.
I used to do that back in kernel 2.0 days already.
It's nice to know you can nuke the contents of the slave dir and not
lose any data. ;-) Also I made the slave directory writable by the name
server, the master directory not. There are a couple of reasons to do
such things
(e.g. if you have zones with dynamic updates enabled, you might also
want to put them into a separate directory, while keeping the "root"
zone files protected.
I for example have a dyn.domain.tld zone which is updateable, and some
CNAMES
from the static zone file pointing in there)

best regards,
Erich Schubert
-- 
    erich@(vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C   (o_
   There was never a good war or a bad peace. - Benjamin Franklin   //\
    Mathematik: Das Alphabet, mit dessen Hilfe Gott das Universum   V_/_
                beschrieben hat. --- Galileo Galilei


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

Re: correct way to set context in perl?

[Maria Iano]

Hi Eric,

Thanks for your response. The master and slave directories are separate. The zones are divided into over a hundred different groups (and growing). Individual users have access to edit zones in some groups and not others. Each group has its own directory. Under each group's directory are the master and slave directories. As new groups are created (by the perl scripts), new directories need to be created (as well as new files) and I need to be able to give them the correct security contexts, and there will be two different types under each group directory.

It looks like this:

                                 data
                                  |
      ___________________________________________________________
     |                      |
    grp1                   grp2          ... and so on ...
     |                      |
  __________          ____________
  |        |          |           |
master   slave    master       slave

Of course I built this directory structure with no thought of selinux at the time. Perhaps I should just redo the directory structure so anything new created just inherits the correct context.

Thanks,
Maria

On Thu, May 18, at 10:47%P so wrote Erich Schubert (erich@debian.org):

> Hi,
> I'd recommend to use different directories for master and slave zones.
> I used to do that back in kernel 2.0 days already.
> It's nice to know you can nuke the contents of the slave dir and not
> lose any data. ;-) Also I made the slave directory writable by the name
> server, the master directory not. There are a couple of reasons to do
> such things
> (e.g. if you have zones with dynamic updates enabled, you might also
> want to put them into a separate directory, while keeping the "root"
> zone files protected.
> I for example have a dyn.domain.tld zone which is updateable, and some
> CNAMES
> from the static zone file pointing in there)
> 
> best regards,
> Erich Schubert
> -- 
>     erich@(vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C   (o_
>    There was never a good war or a bad peace. - Benjamin Franklin   //\
>     Mathematik: Das Alphabet, mit dessen Hilfe Gott das Universum   V_/_
>                 beschrieben hat. --- Galileo Galilei

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

Re: correct way to set context in perl?

[Erich Schubert]

Hi,
You should be able to setup a regexp to match the master and slave dirs
with appropriate contexts, then run the "restorecon" app to restore the
directory contexts after dir creation and it should work okay. You'll
need your app to be able to transition into restorecon, but thats
probably okay. I mean, it could be used to reset some file contexts
in /home that you'd like to keep...
Maybe restorecon will work on the files without domain transition, if
the old domain has the relabel permissions... I'm not that deep into
advanced SELinux use...

best regards,
Erich Schubert
-- 
     erich@(vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C    (o_
 Nothing prevents happiness like the memory of happiness. --- A. Gide //\
    Wo befreundete Wege zusammenlaufen, da sieht die ganze Welt für   V_/_
          eine Stunde wie eine Heimat aus. --- Herrmann Hesse



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

Re: correct way to set context in perl?

[Russell Coker]

On Friday 19 May 2006 07:12, Maria Iano <maria@iano.org> wrote:
> Thanks for your response. The master and slave directories are separate.
> The zones are divided into over a hundred different groups (and growing).
> Individual users have access to edit zones in some groups and not others.
> Each group has its own directory. Under each group's directory are the
> master and slave directories. As new groups are created (by the perl
> scripts), new directories need to be created (as well as new files) and I
> need to be able to give them the correct security contexts, and there will
> be two different types under each group directory.

Why would each group require a separate slave directory?

The only reason why a user might need direct access to the slave directory is 
to read files (for converting a slave into a master) and to unlink files 
(after removing them from the BIND configuration).

Given that DNS data is essentially public allowing all groups to read each 
other's data is not going to do any harm.  Also as the data is regenerated as 
needed and always kept fresh the unlink problem can be solved by a cron job 
that runs once per month and deletes old slave files.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

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

Re: correct way to set context in perl?

[Maria Iano]

I agree. Nobody actually needs to deal with the individual files anyway - it's all done by scripts through a web interface. It was just a convenience for me to have the groups of domains all separate. I've decided to move all the zones into the more traditional structure of having all masters under a master directory and all slaves under a slave directory. This will mean that the scripts automatically create the files with the correct types. It will make a directory listing slower but that's not a big deal.

So for now I don't need to know the best approach to have a perl script set the security context of a file. I would guess that I will need to do it at some point in the future - if not for this application then for something else. I would really appreciate if someone could help me understand the best approach for this. Is it best to design and code to avoid having to do it (as in this case where I redesigned the directory structure)? If so, I'd like to know why.

Thanks,
Maria
 
On Fri, May 19, at 11:57%P so wrote Russell Coker (russell@coker.com.au):

> On Friday 19 May 2006 07:12, Maria Iano <maria@iano.org> wrote:
> > Thanks for your response. The master and slave directories are separate.
> > The zones are divided into over a hundred different groups (and growing).
> > Individual users have access to edit zones in some groups and not others.
> > Each group has its own directory. Under each group's directory are the
> > master and slave directories. As new groups are created (by the perl
> > scripts), new directories need to be created (as well as new files) and I
> > need to be able to give them the correct security contexts, and there will
> > be two different types under each group directory.
> 
> Why would each group require a separate slave directory?
> 
> The only reason why a user might need direct access to the slave directory is 
> to read files (for converting a slave into a master) and to unlink files 
> (after removing them from the BIND configuration).
> 
> Given that DNS data is essentially public allowing all groups to read each 
> other's data is not going to do any harm.  Also as the data is regenerated as 
> needed and always kept fresh the unlink problem can be solved by a cron job 
> that runs once per month and deletes old slave files.
> 
> -- 
> http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
> http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
> http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
> http://www.coker.com.au/~russell/  My home page

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

Re: correct way to set context in perl?

[Maria Iano]

Even after reorganizing the directories I still see the need for setting context from a perl script. The first time the application runs the directories may not be there. So I've added this to one of the scripts, and it does seem to do what I need. I would appreciate any comments/advice on a better approach to this:

unless ($zonepath) {
    die "The zone path was not found in the configuration file";
}
unless (-e $zonepath) {
    die "Could not create directory $zonepath" unless mkdir($zonepath,0770);
    system ("chcon","system_u:object_r:named_zone_t","$zonepath");
    die "Could not create directory $zonepath/slaves"
                  unless mkdir("$zonepath/slaves",0770);
    system ("chcon","system_u:object_r:named_cache_t","$zonepath/slaves");
}
my $datapath = "$zonepath/master";
unless (-e $datapath) {
    die "Could not create directory $datapath" unless mkdir($datapath,0770);
    system ("chcon","system_u:object_r:named_zone_t","$datapath");
}

On Fri, May 19, at 10:31%P so wrote Maria Iano (maria@iano.org):

> I agree. Nobody actually needs to deal with the individual files anyway - it's all done by scripts through a web interface. It was just a convenience for me to have the groups of domains all separate. I've decided to move all the zones into the more traditional structure of having all masters under a master directory and all slaves under a slave directory. This will mean that the scripts automatically create the files with the correct types. It will make a directory listing slower but that's not a big deal.
> 
> So for now I don't need to know the best approach to have a perl script set the security context of a file. I would guess that I will need to do it at some point in the future - if not for this application then for something else. I would really appreciate if someone could help me understand the best approach for this. Is it best to design and code to avoid having to do it (as in this case where I redesigned the directory structure)? If so, I'd like to know why.
> 
> Thanks,
> Maria
>  
> On Fri, May 19, at 11:57%P so wrote Russell Coker (russell@coker.com.au):
> 
> > On Friday 19 May 2006 07:12, Maria Iano <maria@iano.org> wrote:
> > > Thanks for your response. The master and slave directories are separate.
> > > The zones are divided into over a hundred different groups (and growing).
> > > Individual users have access to edit zones in some groups and not others.
> > > Each group has its own directory. Under each group's directory are the
> > > master and slave directories. As new groups are created (by the perl
> > > scripts), new directories need to be created (as well as new files) and I
> > > need to be able to give them the correct security contexts, and there will
> > > be two different types under each group directory.
> > 
> > Why would each group require a separate slave directory?
> > 
> > The only reason why a user might need direct access to the slave directory is 
> > to read files (for converting a slave into a master) and to unlink files 
> > (after removing them from the BIND configuration).
> > 
> > Given that DNS data is essentially public allowing all groups to read each 
> > other's data is not going to do any harm.  Also as the data is regenerated as 
> > needed and always kept fresh the unlink problem can be solved by a cron job 
> > that runs once per month and deletes old slave files.
> > 
> > -- 
> > http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
> > http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
> > http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
> > http://www.coker.com.au/~russell/  My home page
> 
> --
> 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.

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

Re: correct way to set context in perl?

[Stephen Smalley]

On Fri, 2006-05-19 at 11:33 -0400, Maria Iano wrote:
> Even after reorganizing the directories I still see the need for setting context from a perl script. The first time the application runs the directories may not be there. So I've added this to one of the scripts, and it does seem to do what I need. I would appreciate any comments/advice on a better approach to this:
> 
> unless ($zonepath) {
>     die "The zone path was not found in the configuration file";
> }
> unless (-e $zonepath) {
>     die "Could not create directory $zonepath" unless mkdir($zonepath,0770);
>     system ("chcon","system_u:object_r:named_zone_t","$zonepath");
>     die "Could not create directory $zonepath/slaves"
>                   unless mkdir("$zonepath/slaves",0770);
>     system ("chcon","system_u:object_r:named_cache_t","$zonepath/slaves");
> }
> my $datapath = "$zonepath/master";
> unless (-e $datapath) {
>     die "Could not create directory $datapath" unless mkdir($datapath,0770);
>     system ("chcon","system_u:object_r:named_zone_t","$datapath");
> }

If using chcon, use the -t option so that you only need to specify the
type (named_zone_t) and let the rest of the context be inferred.
Ideally, you'd get even the type name from some config file.

python bindings have been added to libselinux via swig; generating perl
bindings might be simple, particularly for simple functions like
setfilecon(3).

-- 
Stephen Smalley
National Security Agency


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

Re: correct way to set context in perl?

[Maria Iano]

You're right - I'll move the context types into the config file. I'll use the -t option as you suggest as well. Thanks very much for your help.

I have a pair of .te and .fc files for my application, so next time it boots they will get labelled correctly anyway.

Generating perl bindings is probably way out of my league, but I will take a look at it.

Every time a zone is edited, the scripts append the diffs to a running log file of diffs for that zone. These files are kept in a directory called diffs and the name server never needs to read or write to them, so I gave it type etc_t because I don't know any better. So here is how it looks now:

my $namedpath;
if ($ARGV[0] =~ /--dir=([^)]+)/) {
    $namedpath = $1;
} else {
    $namedpath = $config->{fulldirectory};
}
my $master_type = $config->{master_type} || 'named_zone_t';
my $slave_type = $config->{slave_type} || 'named_cache_t';
my $diff_type = $config->{diff_type} || 'etc_t';
my $named_dir_type = $config->{named_dir_type} || $master_type;

unless ($namedpath) {
    die "The zone path was not found in the configuration file";
}
unless (-e $namedpath) {
    die "Could not create directory $namedpath" unless mkdir($namedpath,0770);
    system ('chcon','-t',$named_dir_type,"$namedpath");
}
unless (-e "$namedpath/slaves") {
    die "Could not create directory $namedpath/slaves"
                  unless mkdir("$namedpath/slaves",0770);
    system ('chcon','-t',$slave_type,"$namedpath/slaves");
}
unless (-e "$namedpath/diffs") {
    die "Could not create directory $namedpath/diffs"
                  unless mkdir("$namedpath/diffs",0770);
    system ('chcon','-t',$diff_type,"$namedpath/diffs");
}
my $masterpath = "$namedpath/master";
unless (-e $masterpath) {
    die "Could not create directory $masterpath" unless mkdir($masterpath,0770);
    system ('chcon','-t',$master_type,"$masterpath");
}

Thanks for your help,
Maria

On Fri, May 19, at 11:44%P so wrote Stephen Smalley (sds@tycho.nsa.gov):

> On Fri, 2006-05-19 at 11:33 -0400, Maria Iano wrote:
> > Even after reorganizing the directories I still see the need for setting context from a perl script. The first time the application runs the directories may not be there. So I've added this to one of the scripts, and it does seem to do what I need. I would appreciate any comments/advice on a better approach to this:
> > 
> > unless ($zonepath) {
> >     die "The zone path was not found in the configuration file";
> > }
> > unless (-e $zonepath) {
> >     die "Could not create directory $zonepath" unless mkdir($zonepath,0770);
> >     system ("chcon","system_u:object_r:named_zone_t","$zonepath");
> >     die "Could not create directory $zonepath/slaves"
> >                   unless mkdir("$zonepath/slaves",0770);
> >     system ("chcon","system_u:object_r:named_cache_t","$zonepath/slaves");
> > }
> > my $datapath = "$zonepath/master";
> > unless (-e $datapath) {
> >     die "Could not create directory $datapath" unless mkdir($datapath,0770);
> >     system ("chcon","system_u:object_r:named_zone_t","$datapath");
> > }
> 
> If using chcon, use the -t option so that you only need to specify the
> type (named_zone_t) and let the rest of the context be inferred.
> Ideally, you'd get even the type name from some config file.
> 
> python bindings have been added to libselinux via swig; generating perl
> bindings might be simple, particularly for simple functions like
> setfilecon(3).
> 
> -- 
> Stephen Smalley
> National Security Agency

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

Re: correct way to set context in perl?

[Russell Coker]

On Saturday 20 May 2006 00:31, Maria Iano <maria@iano.org> wrote:
> So for now I don't need to know the best approach to have a perl script set
> the security context of a file. I would guess that I will need to do it at
> some point in the future - if not for this application then for something
> else. I would really appreciate if someone could help me understand the
> best approach for this. Is it best to design and code to avoid having to do
> it (as in this case where I redesigned the directory structure)? If so, I'd
> like to know why.

I am not a great Perl programmer, so I probably can't give the best answer to 
this.

I believe that it is possible to call any system call from Perl, so you could 
set the XATTR values directly, but to correctly support MCS/MLS you need a 
Perl interface to libselinux (which is quite possible, we just need someone 
to write it).

Another possibility is to execute chcon.  If you only have a small number of 
files to relabel (or if you are using the -R option) then the performance 
overhead will be negligible.

Finally if the file contexts that you desire match the file_contexts file then 
you can execute restorecon.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

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

Re: correct way to set context in perl?

[Maria Iano]

Thank you all for your time and help with this. Using restorecon works well and I only need to store the correct context information in one place so that's the way to go. I am very impressed at how easy it was to write a couple of .te and .fc files and adapt my scripts. SELinus has been extremely well designed and implemented - thank you!

Maria


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