Installation and use without root access?

[sempai]

Hello,

I'm in a position where it would be advantageous to run ossec-hids as
a server by an unprivileged user.

Has anyone already gone down this road before and written
documentation or shared their installation details?

[Jason 'XenoPhage' Frisvold]

Wouldn't running as an unprivileged user significantly reduce the functionality?

---------------------------
Jason 'XenoPhage' Frisvold
xeno...@godshell.com
---------------------------
"Any sufficiently advanced magic is indistinguishable from technology."
- Niven's Inverse of Clarke's Third Law

[Carl Gaudreault]

Hi,

I am currently getting a lot of emails in regards to a php issue on the
server... ...this issue is not really a major problem, the server should
run without any problem even if i can see this in the logs...

...therefore, i would like to add an exception in Ossec, to stop
receiving those emails... here is the email i am getting... could
someone tell me exactly what to do to add an exception for it?? (i am
new to OSSEC... ...so please explain step by step ;o)

Received From: i51->/var/log/messages
Rule: 1002 fired (level 2) -> "Unknown problem somewhere in the system."
Portion of the log(s):

Apr 17 11:59:00 i51 kernel: xmlrpc[23889]: segfault at 0000000000000000 rip 0000000000416e7d rsp 00000000427080a0 error 4

[Michael Starks]

On Thu, 14 Apr 2011 10:15:28 -0700 (PDT), sempai <sem...@hellyeah.com>
wrote:

OSSEC can be installed without root access but the install script would
likely fail. It needs to place an init script for startup, one file in
/etc and create the users and groups. Finally, it needs to create
/var/osssec. This can all be done manually, but someone obviously needs
to have some privileges to perform these steps.

OSSEC can be administered with someone who has sudo access to
impersonate/become the ossec user account. I tried this several years
ago. I recall that there was one daemon that failed to start because it
started as root and then dropped privileges. The situation may be
slightly different today since there have been a few more daemons added.
You can probably design a strategy around allowing someone to become the
ossec user then granting sudo root access to perform bin/ossec-control
stop|start|restart, or something along those lines.

--
Michael Starks
[I] Immutable Security
http://www.immutablesecurity.com

[Daniel Cid]

Hi Carl,

A segfault is never good and I would recommend looking at this
application to see why it is crashing. A simple rule to
ignore it:

<rule id="100121" level="0">
<if_sid>1002</if_sid>
<match>^xmlrpc</match>
<regex> segfault at </regex>
<description>Ignoring segaults from xmlrpc</description>
</rule>

thanks,

[Castle, Shane]

A somewhat cursory check of history shows that xmlrpc has had problems over the years but all the hits are now kinda old - think maybe it's an old PHP install and should be upgraded.

I agree that the problem should be fixed and not just ignored.

--
Shane Castle
Data Security Mgr, Boulder County IT
CISSP GSEC GCIH

[sempai]

On Apr 18, 11:12 am, Michael Starks <ossec-l...@michaelstarks.com>
wrote:

>  OSSEC can be administered with someone who has sudo access to
>  impersonate/become the ossec user account. I tried this several years
>  ago. I recall that there was one daemon that failed to start because it

>  started asrootand then dropped privileges. The situation may be

>  slightly different today since there have been a few more daemons added.
>  You can probably design a strategy around allowing someone to become the

>  ossec user then granting sudorootaccess to perform bin/ossec-control

>  stop|start|restart, or something along those lines.

I was hopeful! But I've hit a wall pretty fast because just about
everything generates an error even if you're uid:ossec.

e.g.

hids $ id
uid=500(testuser) gid=500(testgroup) groups=500(testgroup),508(ossec)

hids $ sudo -u ossec /var/ossec/bin/list_agents

OSSEC HIDS list_agents: List available agents.
Available options:
-h This help message.
-a List all agents.
-c List the connected (active) agents.
-n List the not connected (active) agents.

hids $ sudo -u ossec /var/ossec/bin/list_agents -c
2011/05/06 13:18:53 list_agents(1207): ERROR: Unable to switch to
group: 'ossec'.

hids $ sudo -u ossec /var/ossec/bin/list_agents -n
2011/05/06 13:18:56 list_agents(1207): ERROR: Unable to switch to
group: 'ossec'.

hids $ sudo -u ossec /var/ossec/bin/manage_agents -h

OSSEC HIDS manage_agents: Manage agents.
Available options:
-h This help message.
-V Display OSSEC version.
-l List available agents.
-e <id> Extracts key for an agent (Manager only).
-i <id> Import authentication key (Agent only).

hids $ sudo -u ossec /var/ossec/bin/manage_agents
2011/05/06 13:19:05 manage_agents(1207): ERROR: Unable to switch to
group: 'ossec'.

My pilot server is on 2.6.18-238.9.1.el5 #1 SMP Fri Mar 18 12:42:04
EDT 2011 i686 athlon i386 GNU/Linux, RHEL 5.6

Similar issue to:
http://groups.google.com/group/ossec-list/msg/71f6407e123f3de3

But re-installation has no effect.

Any suggestions? My group doesn't want to manage the OS and platform,
we have administrators that do that. We just want to work with ossec
the application so that we can a test HIDS deployment, but we're
puzzled why it's unable to switch to the ossec group.

I can probably convince them to let us have superuser via sudo to run
the ossec-control, but they're going to balk if I say "...and
everything under /var/ossec/bin" due to how they manage the sudoers
across production systems on our campus. They are (rightly) adverse
to one-offs and "special snowflakes".

[dan (ddp)]

It can't switch because you're not root. Make sure "sudo -u ossec"
changes the group as well (and/or try it with "-g ossec" as well).
You may run into other problems running the daemon processes though.
For those you'd have to break out a text editor. (I'm thinking the
chroot code.)

> I can probably convince them to let us have superuser via sudo to run
> the ossec-control, but they're going to balk if I say "...and
> everything under /var/ossec/bin" due to how they manage the sudoers
> across production systems on our campus.  They are (rightly) adverse
> to one-offs and "special snowflakes".
>
>

You don't need sudo access to ossec-control, just the binaries in
/var/ossec/bin (and a couple of quick mods to ossec-control to utilize
sudo).

[sempai]

On Fri, May 6, 2011 at 1:40 PM, dan (ddp) <ddp...@gmail.com> wrote:

> It can't switch because you're not root. Make sure "sudo -u ossec"
> changes the group as well (and/or try it with "-g ossec" as well).
> You may run into other problems running the daemon processes though.
> For those you'd have to break out a text editor. (I'm thinking the
> chroot code.)

My understanding is that sudo runs as root, since it is setuid root.
I should be able to switch to any user or group I want as superuser,
and I have tried setting the user to ossec with `-u ossec` and the
group to ossec with `-g ossec`, and even spawning an ossec uid-owned
shell with group `ossec`.

The binaries in $ossec/bin still report that they cannot switch to
group: 'ossec' even though I am already in the group ossec.

bash-3.2$ id
uid=501(ossec) gid=508(ossec) groups=508(ossec)
bash-3.2$ /var/ossec/bin/manage_agents
2011/05/09 10:51:25 manage_agents(1207): ERROR: Unable to switch to
group: 'ossec'.

I'm aleady group 'ossec'. Why am I trying to switch to it? And more
importantly, why does manage_agents think I'm unable to do so?

> You don't need sudo access to ossec-control, just the binaries in
> /var/ossec/bin (and a couple of quick mods to ossec-control to utilize
> sudo).

So are you saying that they all require root permissions to use those
binaries? Is there no supported mechanism to manage agents and
provision devices without super-user permissions?

You are saying "sudo access", do you mean "sudo root" or "sudo ossec"?

[Daniel Cid]

The issue here is that on the OSSEC code itself (on all daemons), we do:

chroot + setuid + setgid.

Meaning that even if you are running OSSEC as the user "ossec", it
will still try to chroot, setuid, etc. All of those
will fail because only root can do that. Not doing the setuid should
be a simple change (maybe via command line
argument), but removing the chroot is a lot more work since some of
the code expect to be in a chroot and will
use the OSSEC root (/var/ossec) as their main root directory.

thanks,

[Michael Starks]

On Mon, 9 May 2011 13:49:40 -0300, Daniel Cid <danie...@gmail.com>
wrote:

> The issue here is that on the OSSEC code itself (on all daemons), we
> do:
>
> chroot + setuid + setgid.
>
> Meaning that even if you are running OSSEC as the user "ossec", it
> will still try to chroot, setuid, etc. All of those
> will fail because only root can do that. Not doing the setuid should
> be a simple change (maybe via command line
> argument), but removing the chroot is a lot more work since some of
> the code expect to be in a chroot and will
> use the OSSEC root (/var/ossec) as their main root directory.

Ok, now it is making a lot of sense. :) To the original poster, there
are a few ways that can be approached:

1. Add the non-privileged user to the ossec group. You should be able
to at least read the log files, etc, which may be the main point.
2. Optionally, give limited sudo access to some of the ossec binaries,
or maybe even just ossec-control. Something like: sudo
/var/ossec/ossec-control restart. I *think* since ossec-control would be
calling the binaries that it would inherit the rights.
3. It's also possible to set acls on a filesystem that supports it,
such that the permissions can be a bit more granularly defined. This
would allow ossec to run normally under the usual Unix permissions but
you could still have access to all of the files. Although to be truly
effective, you should not be able to execute commands, which ossec-exexd
can do, and if you could modify ossec.conf then you have root access via
proxy.