/etc/init.d/ script

[Bogdan Agica]

Hi again, everybody.

I'm making quite a progress in developing the policy source for
BitDefender, and I want to thank the list again for the tips given so
far.

I'm still running into this weird problem with the /etc/init.d/bd
script. This, in essence, is a very common start/stop script, but with
some functions like stats and info. These functions are trying to read
data from directories labeled bitdefender_etc_t and bitdefender_lib_t.

The problem is: should I want the script to do what it's supposed to do
I have to either:
1. Relabel the script from initrd_exec_t to something else, 
in which case I'll run into problems starting / stopping the programs.
2. Give read access to initrd_t in bitdefender_etc_t and _lib_t, 
which I think is a stupid workaround, providing read access to all
scripts in /etc/init.d to this dir.

I know, the best idea would to leave the /etc/init.d/ script for
starting and stopping the program, and to provide all the other
functionality via other means, but that is not feasible in the short
term.

Is there any way to "inherit" a type (C++like inheritance), e.g. to
create a type (say bitdefender_initrc_exec_t), which inherits all the
attributes of it's successor, but adds new functionality? (Would be a
nice idea if there isn't yet)

TIA, 
-- 
Bogdan Agica
BitDefender Internal Testing Engineer
-------------------------------------
SOFTWIN
Data Security Division
-------------------------------------
email: bagica(a)bitdefender.com
phone: +(4021) 233 18 52; 233 07 80
fax: [phone]
Bucharest, ROMANIA
http://www.bitdefender.com
http://www.softwin.ro
-------------------------------------
secure your every bit
-------------------------------------


-- 
This message was scanned for spam and viruses by BitDefender.
For more information please visit http://www.bitdefender.com/

[Russell Coker]

On Thursday 06 January 2005 02:03, Bogdan Agica <bagica(a)bitdefender.com&gt; 
wrote:
>  1. Relabel the script from initrd_exec_t to something else,
>  in which case I'll run into problems starting / stopping the programs. 
You could have the init.d script call something else to do the work.  So you 
split the script into a worker script in /usr/sbin and a start script in the 
init.d directory that just calls the worker.

>  2. Give read access to initrd_t in bitdefender_etc_t and _lib_t,
>  which I think is a stupid workaround, providing read access to all
>  scripts in /etc/init.d to this dir. 
That's the usual approach.  Not ideal but not too bad either.  What is the 
bitdefender data?  initrc_t is a very powerful domain that can break your 
system in many ways.  Protecting files from it provides little benefit with 
the way things work now.

>  I know, the best idea would to leave the /etc/init.d/ script for
>  starting and stopping the program, and to provide all the other
>  functionality via other means, but that is not feasible in the short
>  term. 
It's not difficult to split a shell script into two shell scripts.

>  Is there any way to "inherit" a type (C++like inheritance),
> e.g. to
>  create a type (say bitdefender_initrc_exec_t), which inherits all the
>  attributes of it's successor, but adds new functionality? (Would be a
>  nice idea if there isn't yet) 
No.

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

[Bogdan Agica]

On Thu, 2005-01-06 at 21:31 +1100, Russell Coker wrote:
>  On Thursday 06 January 2005 02:03, Bogdan Agica
> <bagica(a)bitdefender.com&gt; 
>  wrote:
>  > 1. Relabel the script from initrd_exec_t to something else,
>  > in which case I'll run into problems starting / stopping the programs.
>  
>  You could have the init.d script call something else to do the work.  So you 
>  split the script into a worker script in /usr/sbin and a start script in the 
>  init.d directory that just calls the worker. 
That's probably how we're
gonna do it. Thanx for the tips.

>  > 2. Give read access to initrd_t in bitdefender_etc_t and
> _lib_t,
>  > which I think is a stupid workaround, providing read access to all
>  > scripts in /etc/init.d to this dir.
>  
>  That's the usual approach.  Not ideal but not too bad either.  What is the 
>  bitdefender data?  initrc_t is a very powerful domain that can break your 
>  system in many ways.  Protecting files from it provides little benefit with 
>  the way things work now. 
The data accessed is not very sensitive (only statistics and settings,
not anybody's email messages). However it would be only an workaround,
not a fix.

>  > Is there any way to "inherit" a type (C++like
> inheritance), e.g. to
>  > create a type (say bitdefender_initrc_exec_t), which inherits all the
>  > attributes of it's successor, but adds new functionality? (Would be a
>  > nice idea if there isn't yet)
>  
>  No. 
Are there any plans for this? I guess it would make things easier for a
lot of people.

Thanx again for the reply, 
Bogdan

-- 
Bogdan Agica
BitDefender Internal Testing Engineer
-------------------------------------
SOFTWIN
Data Security Division
-------------------------------------
email: bagica(a)bitdefender.com
phone: +(4021) 233 18 52; 233 07 80
fax: [phone]
Bucharest, ROMANIA
http://www.bitdefender.com
http://www.softwin.ro
-------------------------------------
secure your every bit
-------------------------------------


-- 
This message was scanned for spam and viruses by BitDefender.
For more information please visit http://www.bitdefender.com/

[Russell Coker]

On Friday 07 January 2005 20:30, Bogdan Agica <bagica(a)bitdefender.com&gt; wrote:
>  > > Is there any way to "inherit" a type (C++like
> inheritance), e.g. to
>  > > create a type (say bitdefender_initrc_exec_t), which inherits all the
>  > > attributes of it's successor, but adds new functionality? (Would be a
>  > > nice idea if there isn't yet)
>  >
>  > No.
>
>  Are there any plans for this? I guess it would make things easier for a
>  lot of people. 
This has been requested and rejected in the past, but there have been some 
design changes in the mean time, so it might be better accepted if requested 
again now.

This is not a good list for such a discussion, the main SE Linux list is the 
correct list.  This list is about getting the current SE Linux implementation 
working in Fedora, if you post here about SE Linux feature requests (as 
opposed to requests for Fedora to better use existing SE Linux features) then 
most of the people who need to see such messages probably won't.

I suggest that you subscribe to the NSA list (if you haven't already) and post 
a new message there with your feature request.

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