Access Control for RTEMS Shell

[Joel Sherrill]

On 11/19/2014 4:54 PM, Peter Dufault wrote:
> Are the UID and GID per-thread?  I assume two different telnet sessions would have different credentials.
They can and do now if you want to try the telnetd example. There is an
rtems
and a root account as I recall. One can't write to parts of the
filesystem. :)
> I strongly agree that there is a need for credentials in embedded applications, but I don't see that they can be tied to the RTEMS shell.  I'm not sure how UID and GID work in a single process POSIX thread environment and the little google searching I did ended up with Linux extensions.
We would be adding a little interpretation/extension and we already have
some in place. At this point, the default is to have one set of process
environment settings (e.g. uid, euid, gid, max symlinks to traverse, etc.).

There is RTEMS specific support for a thread to have its own instance of
process environment settings by simply making a call.

At one point (not sure if still in), you could share a process environment
set across a set of threads.

So by default, the entire "process" has the same settings but each thread
can have its own with a little work. It is not tied to the shell and is used
by at least ftpd and telnetd/login.
> Do the credentials apply to file opens or message queue opens?
The credentials are checked on file opens for sure.

This is far from perfect but it is probably as good as it can get in a
single process
environment.

--joel
>> On Nov 19, 2014, at 02:20 , Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
>>
>> The goal is to provide different command sets for different users. For 
>> example a system could give the customer a certain command set and the 
>> service personal a different one which includes also maintenance operations.
>>
>> Most of the infrastructure was already present.  There were just some 
>> missing links in between.
>>
>> On 18/11/14 16:11, Gedare Bloom wrote:
>>> Could you briefly explain a bit more context about the goals for
>>> implementing access control? That is, is it for compliance to some
>>> standard, to address a security need, or something else?
>>>
>>> Thanks,
>>> Gedare
>>>
>>> On Tue, Nov 18, 2014 at 9:37 AM, Sebastian Huber
>>> <sebastian.huber at embedded-brains.de> wrote:
>>>> This patch set adds access control to the RTEMS shell.  The command visibility
>>>> and ability to execute are determined by the current user environment and per
>>>> command mode, UID and GID values.  The user environment is set up by the
>>>> rtems_shell_login_check() handler.  Commands to alter the mode, UID and GID of
>>>> commands are added.
>>>>
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel at rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/devel
>> -- 
>> Sebastian Huber, embedded brains GmbH
>>
>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> Phone   : +49 89 189 47 41-16
>> Fax     : +49 89 189 47 41-09
>> E-Mail  : sebastian.huber at embedded-brains.de
>> PGP     : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
> Peter
> -----------------
> Peter Dufault
> HD Associates, Inc.      Software and System Engineering
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985