:: Re: [DNG] netman GIT project
Page principale
Supprimer ce message
Répondre à ce message
Auteur: Edward Bartolo
Date:  
À: Tobias Hunger
CC: dng, aitor_czr
Sujet: Re: [DNG] netman GIT project
Hi all,

I think, a simple way to avoid the backend having to call external
programs like ifup and ifdown, is to use code belonging to these
programs as it they were functions. This means, their code would be
used like this:

Suppose int main(int argc, char * argv[]) is the main function for
ifup. The main function's name would be changed like this, and the
other code belonging to ifup would be used.

int ifup_main(int argc, char * argv[]);

If I am correct, this should allow the backend to avoid having to use
execl to call ifup or ifdown or whatever other external program.

Edward

On 08/09/2015, Edward Bartolo <edbarx@???> wrote:
> Quote: << Maybe you could get away with setting only one capability on
> the back end instead of handing it full root privileges. Maybe there
> is a group that has special privileges to run the necessary binaries?
> Then you could sgid your back end to that group id, severely limiting
> the damage any exploit that may or may not exist in your code can do
> to the system.>>
>
> This seems to be a good suggestion if I understood you well.
>
> So, you are suggesting to create a user group that would be given
> rights to run the processes the backend calls? This sounds a lesser
> security risk than using a full blown root SUID for backend.
>
> Another way, is to make the backend self contained and do away
> completely with using external process to connect and disconnect, but
> that requires quite a good deal of coding time.
>
> Thanks for your contribution.
>
> Edward
>
> On 08/09/2015, Tobias Hunger <tobias.hunger@???> wrote:
>> Am 08.09.2015 20:30 schrieb "Edward Bartolo" <edbarx@???>:
>>>
>>> Actually, you can do away with using a root SUID for backend as that
>>> was initially how netman was designed. However, there were complaints
>>> that I was adding an extra dependency which simply was a dependency on
>>> sudo being installed. Moreover, my initial proposal that worked, used
>>> sudo in a way to only allow the backend to run; so, it was NOT
>>> configured the way sudo is on Ubuntu.
>>
>> Suid or sudo does not make a big difference: In the end you run the back
>> end with full root privileges.
>>
>> Capabilities were introduced to be able to have "miniroot" users that can
>> change on aspect of the system (e.g. manage the network) but not the
>> others. A significant amount of former SUID binaries were adapted to rely
>> on capabilities instead.
>>
>> Note: With most capabilities you can actually acquire more since they are
>> still too powerful, but that is one extra step an attacker has to make.
>>
>>> Regarding the backend calling external processes, this is done through
>>> execl and popen. Calls to external processes were modified as soon as
>>> I uploaded my unfinished code the first time. There were justified
>>> claims like yours, that there were security issues with my code. I
>>> heeded those advices by actually letting other developers modify the
>>> code so that, security would not be compromised.
>>
>> I have not looked at your code, so I can not comment on whether or not (I
>> think) it is secure or not. But all it takes to have an exploit is to
>> make
>> one little mistake... everybody makes mistakes, so it is a established
>> security best practice to hand out only those privileges necessary to
>> accomplish any task.
>>
>> Maybe you could get away with setting only one capability on the back end
>> instead of handing it full root privileges. Maybe there is a group that
>> has
>> special privileges to run the necessary binaries? Then you could sgid
>> your
>> back end to that group id, severely limiting the damage any exploit that
>> may or may not exist in your code can do to the system.
>>
>> Best Regards,
>> Tobias
>>
>