All of lore.kernel.org
 help / color / mirror / Atom feed
From: justinmattock@gmail.com (Justin P. Mattock)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] yule
Date: Tue, 02 Dec 2008 11:47:16 -0800	[thread overview]
Message-ID: <1228247236.2928.6.camel@unix> (raw)
In-Reply-To: <1228244768.9691.30.camel@gorn>

On Tue, 2008-12-02 at 14:06 -0500, Christopher J. PeBenito wrote:
> > On Sun, Nov 30, 2008 at 3:31 PM, Konrad Azzopardi
> > <konrad.azzopardi@gmail.com> wrote:
> > > Dear all,
> > >
> > > I am confining a service called 'yule' , which is the central server
> > > for the file integrity checker SAMHAIN.
> > >
> > > Something about the server :
> > >
> > > Binary file is at /usr/local/sbin/yule
> > > Startup script is at /etc/rc.d/init.d/yule      --
> > > Config file : /etc/yulerc
> > > Logfiles /var/log/yule(/.*)?
> > > PID file is at /var/run/yule.pid
> > >
> > > It optionally uses mysql and I have put this as a boolean. I would
> > > appreciate if somebody review the files and give me some feedback to
> > > know if i am on the right track.
> > >
> > > I have only one question....When I issue a stop by  /etc/init.d/yule stop
> > > I get all sorts of avc denials, however the daemon still stops. From
> > > the avc denials and also via an strace it is evident that the stop
> > > script is somehow doing a search in all proc directory. What is the
> > > best thing to do here ? Allowing search to all types in /proc or make
> > > a dontaudit and in both cases is there a macro that captures all types
> > > inside /proc {don't think so}.
> 
> Rule-wise I see a few things which seem questionable to me:
> 
> > manage_files_pattern(yule_t,yule_config_t,yule_config_t)
> 
> It seems like you would not want the daemon to modify its own config
> files.
> 
> > allow yule_t yule_exec_t:file execmod;
> 
> Did you really encounter this as a denial?  I wouldn't expect this on an
> executable.  Especially a daemon doing this on its own executable.
> 
> > allow yule_t self:capability { setgid setuid dac_override ipc_lock fowner sys_resource kill sys_ptrace};
> 
> The kill and sys_ptrace capabilities seem weird, as there do not seem to
> be any process sigkill or process ptrace permissions being used in the
> policy.
> 
> 
> Assuming you're interested in getting this upstreamed:
> 
> > /usr/local/sbin/yule	--	    gen_context(system_u:object_r:yule_exec_t,s0)
> 
> Standard (distro) locations should be covered too, such
> as /usr/sbin/yule, not just /usr/local.
> 
> Also the organization of the file should be fixed to match the refpolicy
> style better.
> 

I'm not sure what was committed
or not when this occurred yesterday.
As for policy
I had pulled the refpolicy svn
last Thursday,(thanksgiving day)
then like I said, did a git-pull
yesterday(from linus's tree) 
and viola list error appeared.
Now this morning I pulled the refpolicy
from svn and did not see any such things.
So you got's me with what happened.  

-- 
Justin P. Mattock <justinmattock@gmail.com>

  reply	other threads:[~2008-12-02 19:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-30 14:31 [refpolicy] yule Konrad Azzopardi
2008-11-30 16:17 ` Konrad Azzopardi
2008-12-02 19:06   ` Christopher J. PeBenito
2008-12-02 19:47     ` Justin P. Mattock [this message]
2008-12-02 20:19     ` Konrad Azzopardi
2008-12-02 21:17       ` Konrad Azzopardi

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=1228247236.2928.6.camel@unix \
    --to=justinmattock@gmail.com \
    --cc=refpolicy@oss.tresys.com \
    /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.