sudo not log command

[johnny bobby bee]

Folks,

Long story: I've got conky (system monitor) showing some commands that
root normally would run, so I added myself as a normal user to sudoers
with nopassword:

me ALL=NOPASSWD:/usr/sbin/smartctl
me ALL=NOPASSWD:/sbin/hdparm

Now, these commands get logged every couple minutes to /var/log/auth as
per the conky script.

Short story: how can I get these commands to stop logging every time
they run by me (or conky)?

For the record, this is on Ubuntu Hardy (8.04.1).

[Erik Hahn]

Post by johnny bobby bee
Folks,
Long story: I've got conky (system monitor) showing some commands that
root normally would run, so I added myself as a normal user to sudoers
me ALL=NOPASSWD:/usr/sbin/smartctl
me ALL=NOPASSWD:/sbin/hdparm
Now, these commands get logged every couple minutes to /var/log/auth as
per the conky script.
Short story: how can I get these commands to stop logging every time
they run by me (or conky)?
For the record, this is on Ubuntu Hardy (8.04.1).

I don't know how to do that with sudo, however you could setuid those
programs. If it's a single user system the impact on security shouldn't
be much higher than with nopasswd.

[johnny bobby bee]

Post by Erik Hahn
I don't know how to do that with sudo, however you could setuid those
programs. If it's a single user system the impact on security shouldn't
be much higher than with nopasswd.

suid was my first thought, but I've always heard of security issues with
suid. Don't really know enough though, to be completely honest.

It's primarily a single-user system, although, I do allow guests to use
it when they're over. And wouldn't you imagine the day someone stumbles
upon either smartctl or hdparm and does something funky (destroys) my HDDs.

Still hope there's just an easy way to stop the logging of those commands.

[Erik Hahn]

Post by johnny bobby bee

Post by Erik Hahn
I don't know how to do that with sudo, however you could setuid those
programs. If it's a single user system the impact on security shouldn't
be much higher than with nopasswd.

suid was my first thought, but I've always heard of security issues with
suid. Don't really know enough though, to be completely honest.
It's primarily a single-user system, although, I do allow guests to use
it when they're over. And wouldn't you imagine the day someone stumbles
upon either smartctl or hdparm and does something funky (destroys) my HDDs.

Create a group and add only yourself and root to it. Make this group the
owner of hdparm and smartctl, then give only owner and group the
permission to read the bins. That way only members of the group can
execute the programs even if it's setuid.

Maybe you can get the information from somewhere in /proc or /sys as
well.

[johnny bobby bee]

Post by Erik Hahn
Create a group and add only yourself and root to it. Make this group the
owner of hdparm and smartctl, then give only owner and group the
permission to read the bins. That way only members of the group can
execute the programs even if it's setuid.

Hm -- that sure is something to chew on. Will give that a go.

Post by Erik Hahn
Maybe you can get the information from somewhere in /proc or /sys as
well.

Ya, been hunting around those parts, too; but can't find what I'm
looking for, yet.

Thanks for the inspiration.

[John Hasler]

Post by johnny bobby bee
Long story: I've got conky (system monitor) showing some commands that
root normally would run, so I added myself as a normal user to sudoers
me ALL=NOPASSWD:/usr/sbin/smartctl
me ALL=NOPASSWD:/sbin/hdparm
Now, these commands get logged every couple minutes to /var/log/auth as
per the conky script.
Short story: how can I get these commands to stop logging every time
they run by me (or conky)?

Disable logging in /etc/sudoers. 'man sudoers' to learn how.

[johnny bobby bee]

Post by John Hasler
Disable logging in /etc/sudoers. 'man sudoers' to learn how.

A real shining beacon there, John. Don't you think I googled or read the
man pages? Sadly, didn't learn how, that's why I'm here asking for some
help. Care to give a confused soul a clue?

[David W. Hodgins]

Post by johnny bobby bee

Post by John Hasler
Disable logging in /etc/sudoers. 'man sudoers' to learn how.

A real shining beacon there, John. Don't you think I googled or read the
man pages? Sadly, didn't learn how, that's why I'm here asking for some

In /etc/sudoers ...
# Defaults specification
Defaults logfile=/dev/null

This turns off all sudo logging. I don't see a way to only turn it off
for one command.

Regards, Dave Hodgins

[johnny bobby bee]

Post by David W. Hodgins
In /etc/sudoers ...
# Defaults specification
Defaults logfile=/dev/null
This turns off all sudo logging. I don't see a way to only turn it off
for one command.

Thanks, I kinda got the jist of that from the Man page, I was hoping
there was a way for specific commands.

cheers.

[Chris Davies]

Post by David W. Hodgins
In /etc/sudoers ...
# Defaults specification
Defaults logfile=/dev/null
This turns off all sudo logging. I don't see a way to only turn it off
for one command.

The man page (for Debian) gives an example of how to do this. Quoting
verbatim:

# Override built-in defaults
Defaults syslog=auth
Defaults>root !set_logname
Defaults:FULLTIMERS !lecture
Defaults:millert !authenticate
***@SERVERS log_year, logfile=/var/log/sudo.log
Defaults!PAGERS noexec

Chris

[johnny bobby bee]

Post by Chris Davies
The man page (for Debian) gives an example of how to do this. Quoting
# Override built-in defaults
Defaults syslog=auth
Defaults>root !set_logname
Defaults:FULLTIMERS !lecture
Defaults:millert !authenticate
Defaults!PAGERS noexec

Either my eyes or my brain are deteriorating. But i still don't see it.

Why must some people purposely _make_ things difficult? Why can't you
just say, "to disable sudo logging for one specific command do this ..."

[David W. Hodgins]

Post by johnny bobby bee
Why must some people purposely _make_ things difficult? Why can't you
just say, "to disable sudo logging for one specific command do this ..."

As far as I can see, there is not way to do it for just one command. Either
sudo logs to syslog, or it doesn't.

The options, as I see it, include letting it log everything, not logging
anything, or finding a way to do what you're currently doing via sudo,
some way that doesn't involve using sudo.

Regards, Dave Hodgins

[johnny bobby bee]

Post by David W. Hodgins
As far as I can see, there is not way to do it for just one command. Either
sudo logs to syslog, or it doesn't.

That's what I see, too. Just wondering why Chris quoted that section of
the man page and insisted the answer was right in front of my eyes.
Well, I didn't see it by what he quoted, nor in any part of the man page.

Post by David W. Hodgins
The options, as I see it, include letting it log everything, not logging
anything, or finding a way to do what you're currently doing via sudo,
some way that doesn't involve using sudo.

I've had to settle with suid on the two commands I need as a normal
user. I did what Erik suggested, created a group with just myself and
root, chown the commands to root:newgroup and took permissions off the 2
commands for other users, then did the suid. Works fine, I guess. I can
run the commands as root now, and nobody else can run the commands. So
it's a solution, but not what I was looking for.

cheers.

[Chris Davies]

Post by johnny bobby bee
Either my eyes or my brain are deteriorating. But i still don't see it.

Please accept my apology. Having initially thought "duh this is easy"
I tried to do it. Which meant reading the man page properly. Which meant
that I discovered you /can't/ do what you want. Oh well, at least I've
learnt something new about sudo today.

I'd be inclined either to sudo the entire script that calls your two
commands, or to do what someone else has already suggested and give
them root access with setuid but restrict who can execute them by group
access control.

Chris

[johnny bobby bee]

Post by Chris Davies
I'd be inclined either to sudo the entire script that calls your two
commands, or to do what someone else has already suggested and give
them root access with setuid but restrict who can execute them by group
access control.

Sudo(ing) the script will still log the commands every min/two and i
don't want that.

Setting suid works for the 2 commands, so i can run the command
completely with all options/switches, but I didn't really need that,
it's a bit overkill.

And, here's the most interesting thing:
If I try setting chown to root for the script then setting suid on the
script only, it won't work.

So with suid set on /usr/sbin/smartctl, I can do, with no problem:
smartctl -a /dev/sda | grep -i temp

But if i take the suid bit off of smartctl and put it only on a script
that just has that same command it won't work.

[Lew Pitcher]

On October 7, 2008 17:57, in comp.os.linux.misc, johnny bobby bee

Post by johnny bobby bee

Post by Chris Davies
I'd be inclined either to sudo the entire script that calls your two
commands, or to do what someone else has already suggested and give
them root access with setuid but restrict who can execute them by group
access control.

Sudo(ing) the script will still log the commands every min/two and i
don't want that.
Setting suid works for the 2 commands, so i can run the command
completely with all options/switches, but I didn't really need that,
it's a bit overkill.
If I try setting chown to root for the script then setting suid on the
script only, it won't work.

Yes, in Linux, scripting languages don't recognize the setuid bit on script
files. The setuid bit is known to be a security exposure when used on a
script file.

Post by johnny bobby bee
smartctl -a /dev/sda | grep -i temp
But if i take the suid bit off of smartctl and put it only on a script
that just has that same command it won't work.

So, write a wrapper program that uses the system() call to launch your
smartctl/grep pipeline, and make the /program/ setuid.

Something like

#include <stdio.h>
#include <stdlib.h>
int main(void)
{
int rc;

if (rc = system("smartctl -a /dev/sda | grep -i temp") == -1)
return 127;
else
return rc;
}

compiled, owned by root, with the setuid bit set


HTH

[johnny bobby bee]

Post by Lew Pitcher
Yes, in Linux, scripting languages don't recognize the setuid bit on script
files. The setuid bit is known to be a security exposure when used on a
script file.

Has this always been the case? In my research I came across a few
examples of folks doing just that and claiming it worked. I gave up when
It wouldn't work for me.

Post by Lew Pitcher
So, write a wrapper program that uses the system() call to launch your
smartctl/grep pipeline, and make the /program/ setuid.
HTH

It does, help; yes, thank you. Although, I've never written a program
wrapper before, so, I'll have to investigate and look yours over and
over and ...

cheers.

[David W. Hodgins]

Post by johnny bobby bee
Has this always been the case? In my research I came across a few
examples of folks doing just that and claiming it worked. I gave up when
It wouldn't work for me.

The script is read, and processed by /bin/bash, or whichever scripting
program you've selected.

My understanding is that you'd have to run /bin/bash with setuid, which
would be a really bad idea.

Btw, the way to disable sudo syslog logging completely, is to include
a line in /etc/sudoers with ...
Defaults !syslog

Regards, Dave Hodgins

[Ralf Fassel]

* Lew Pitcher <***@teksavvy.com>
| So, write a wrapper program that uses the system() call to launch your
| smartctl/grep pipeline, and make the /program/ setuid.
--<snip-snip>--
| if (rc = system("smartctl -a /dev/sda | grep -i temp") == -1)

I would think that this calls the first 'smartctl' and 'grep' programs
it finds in the current PATH setting. Better reset the environment to
something suid-safe and/or use one of the execv* calls...

R'

[Sebastian Wiesner]

Lew Pitcher at Mittwoch 08 Oktober 2008 00:13

Post by Lew Pitcher

Post by johnny bobby bee
smartctl -a /dev/sda | grep -i temp
But if i take the suid bit off of smartctl and put it only on a script
that just has that same command it won't work.

So, write a wrapper program that uses the system() call to launch your
smartctl/grep pipeline, and make the /program/ setuid.
Something like
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
int rc;
if (rc = system("smartctl -a /dev/sda | grep -i temp") == -1)
return 127;
else
return rc;
}
compiled, owned by root, with the setuid bit set

Did you never think of what would happen, if a user does
"export PATH=~; echo 'rm -rf /' > ~/smartctl; chmod a+x ~/smartctl" before this tool gets called?

This wrapper gets called with the caller's environment, thus of this environment. The user could point $PATH to his own "smartctl" or do some nasty tricks with $IFS to manipulate shells, that don't reset $IFS to reasonable values at invocation (which does fortunately not affect bash).

system() and suid should not be used, not alone and definitely not in combination. fork() and the exec* family of functions replace the first, and sudo or POSIX file capabilities serve as a replacement for the latter.


Btw, the return value of system() is not the exit status of the called program. You will have to wrap "rc" into a call to WEXITSTATUS() as defined in "sys/wait.h".

- --
Freedom is always the freedom of dissenters.
(Rosa Luxemburg)

[Chris Davies]

Post by Lew Pitcher
Something like
if (rc = system("smartctl -a /dev/sda | grep -i temp") == -1)
compiled, owned by root, with the setuid bit set

Arrggyyy.

cat >/tmp/smartctl <<xxEOFxx
#!/bin/sh
exec 1>&2
/bin/bash -i
xxEOFxx
chmod a+x /tmp/smartctl
export PATH=/tmp:$PATH
/run/your/setuid/script

Chris

[John Hasler]

Post by John Hasler
Disable logging in /etc/sudoers. 'man sudoers' to learn how.
A real shining beacon there, John. Don't you think I googled or read the
man pages?

Why would I? Most people don't and you did not say that you had.

Post by John Hasler
Care to give a confused soul a clue?

I see that someone else already has.

[johnny bobby bee]

Post by John Hasler
Why would I? Most people don't and you did not say that you had.

No, I guess I didn't actually say that I had, and considering 'most'
people are n00bs, I guess you're right. But, seeing that I already gave
myself access to those 2 commands without passwd, might have told you I
investigated this some, either man page or google, no?

Post by John Hasler
I see that someone else already has.

Yes, but not what I asked or was looking for. Just disable logging for
those 2 specific commands. Not _all_ sudo use.

I guess the suid way might be the better option.

[Sebastian Wiesner]

johnny bobby bee at Freitag 03 Oktober 2008 23:43

Post by johnny bobby bee
Folks,
Long story: I've got conky (system monitor) showing some commands that
root normally would run, so I added myself as a normal user to sudoers
me ALL=NOPASSWD:/usr/sbin/smartctl
me ALL=NOPASSWD:/sbin/hdparm
Now, these commands get logged every couple minutes to /var/log/auth as
per the conky script.
Short story: how can I get these commands to stop logging every time
they run by me (or conky)?
For the record, this is on Ubuntu Hardy (8.04.1).

You can configure syslog to drop all messages to the auth facility, which contain the names of these programs. I don't know, which syslog daemon is used by kubuntu, but afaik syslog-ng and metalog support this.

Post by johnny bobby bee
--
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously.
--Benjamin Franklin