From: Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>
To: kees@schoen.nl, linux-kernel@vger.kernel.org
Subject: Re: [RFC] exec_via_sudo
Date: Tue, 10 Apr 2001 12:04:34 -0500 (CDT) [thread overview]
Message-ID: <200104101704.MAA02175@tomcat.admin.navo.hpc.mil> (raw)
kees <kees@schoen.nl>:
>
> Hi
>
> Unix/Linux have a lot of daemons that have to run as root because they
> need to acces some specific data or run special programs. They are
> vulnerable as we learn.
> Is there any way to have something like an exec call that is
> subject to a sudo like permission system? That would run the daemons
> as a normal user but allow only for specific functions i.e. NOT A SHELL.
> comments?
Simple answer: no.
1. The exec system call (or library) has no way to communicate with the
user for getting a password.
2. A user is not always present when the exec is done (cron/at/batch...).
there is no terminal like device available.
3. In the cases where terminals are available, which terminal? The program
doing the exec may have been detatched (background/nohup...).
4. In the cases where the user is connected via a window - there is no
known way to provide that communication. (the DISPLAY environment might
not be present...)
More complex answer: in some cases.
If the application doing the exec is programmed to, then it may open
an input type and actually use "sudo" to start another program. It will
be up to the implementation of "sudo" to accept the communication path
and perform suitable validation.
The primary weakness in this is that the communication path may not be
trusted by sudo... terminals type devices are easier to validate than
others (windowing systems for instance).
The problem with cron/at/batch cannot be solved since the user context
for any authentication path is missing. It would be necessary to authenticate
the communication path, before authenticating to sudo...
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
next reply other threads:[~2001-04-10 17:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-10 17:04 Jesse Pollard [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-04-10 10:55 [RFC] exec_via_sudo kees
2001-04-10 11:16 ` Tim Waugh
2001-04-10 11:36 ` Alexander Viro
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=200104101704.MAA02175@tomcat.admin.navo.hpc.mil \
--to=pollard@tomcat.admin.navo.hpc.mil \
--cc=kees@schoen.nl \
--cc=linux-kernel@vger.kernel.org \
/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.