Create Sudoers policy for preference App

[Hierosme]

Sudoers is not the best policy system but that is the default helloSystem one, And actually the only one.

We should start a fine tuning of sudoers policy.

It have two big part:
1)
The system default config -> Ultra important section if allow or not certain VAR to be maintain by parent and child during a sudo
Take a look on the /usr/local/etc/sudoers.conf file, That is the original configuration file. Every option have a commentary and a explanation.
Aat the end of it file the directory /usr/local/etv/sudoers.d/ is loaded for get policies.

The system policy require less work, but we have ton consider each of our Application and creat a policy for each one.
Policies can be really power full, we can decide if a password is require , if the user is a Admin etc etc ....

I dont know really by where start:

• /usr/local/etc/sudoers.conf and /usr/local/etc/sudoers.d are normaly model file to be copied in to default sysconfig directory (/etc)
• We should track policy Application by application, and let ultra short place to security issue.
• Where store our sudoers policy ?
• What is teh process to add / update or remove a sudoers policy (By example for a new app)

PS: I dont know when and dont know how but we'll change the world ...

[probonopd]

Why do you think we need to change anything? We have not needed that so far. Whenever the user wants to do something that needs root rights, then sudo will ask the user for the password.

[Hierosme]

In fact i dont think , we have to fine tune sudoers, i'm sure about it.

Then why ?

Because that is require as Security Policy, the defaut Sudo Policy are far away to can make the job. (Especially without apply Button on the App).

Each time i do my best for give a True responce, but here i have impresion of a joke ... Are you kicking me or something like that ? My english is a bit limited for joke ...

Sorry i totally not folow you ...

Then not use Polkit and not use Sudoers ? and nothing more ?

I not want to be rude, i really not understand you point ...

[probonopd]

One way would be to run the whole GUI application as root, like sudo -A -E "dateandtime.py". I think we already have some other apps like this, but it is not best practice.

A better was way is to have small helper scripts (command line tools) that get called by the main GUI application when needed to do the actual work. Those can be invoked with sudo. The advantage is that the main GUI application will not need root rights this way. It't the cleaner way.

I not want to be rude, i really not understand you point ...

I think that just sudo, without sudoers changes, should be enough to do the job. Maybe I am overlooking something?

[Hierosme]

I am overlooking something?

• Look to be exactlly the propose of sudoers framework.
• Each time the best for helloSystem users should be the choise ...

at frist yes we need something like a pipe line Bus, in charge to abstract permission for the Application.
I have thing of a CLI component too. But if you take a moment arround the manual of sudoers, you'll understand the App it self can be use as it component, and that is the way of sudoers frameworks.

root and a user escalation permission are nto similar ...

Root is totally alowed to escape a SHELL an keep root permission, but that is totaly not the case for a user .. The user have to ask for pernission escalation , and the sudoers policy framework is in charge to remove them ... (or not)

I personally not thinking about Sudo Teaam are so stupid to developp and maintaim a complet security policy system for nothing ...

i'll simply wait for someone it show me the way. ... without Polikt and without Sudoers i dont know how to ...

About sudoe -E

sudo -E is more as a bad practice that a security hole for hellosystem users. It have no technical raison to use it.

I hope that exchange can help, or that will stop my work arround Preference App because i have no more way to make it work ....

[Hierosme]

Just for keeo trace:
The docment is a good start point for understand the power of Sudo
https://www.ixsystems.com/blog/best-practices-in-unix-access-control-with-sudo/

IT have no need of LDAP, sudo can work like that out of the box

[probonopd]

Let's keep in mind that helloSystem is about doing things in the most simple way possible.

[Hierosme]

For keep it simple we should follow Sudo best practice..

The actual aproch is simple yes, but expose the system and users to security holes.
For me that a simple: Security dont matter .... No Plan i more simple ....

Actually i not understand how go a head. it have no security policy system, no way to have one,

That is not because i dont want, that because i cant without "working security design".
I really have take time to explain, provide informations, documents .... it look i simply lost my time...

That issue cant be fixed, and will inform users about a huge security holes and the lake of maturity require to fixe it type of security trouble.

Each time the choice should be The best for the helloSytem users.

i make a summary of what i understand :

• helloSystem maintain huge security holes by design.... and it have no plan for fixe it ...
• security fixe and tracking is out of scope
• The no security policy from Sudo default configuration is the main security policy of helloSyem ....
• helloSystem do not respect requirement of XFreeDesktop arround policy kit, this is replace by no security policy of Sudo.
• no security plan is the Plan

Dont need to be cross about me, Orignally i just work for make thing better, i havnt imagine that situation...
I have trying to make think move, i have do my best for, but here that certainly the maximum i can ....

[probonopd]

Using sudo for everything that requires root permissions is the plan. Why should that be insecure?

[Hierosme]

You question have no sense to me, that is write and explain on all documentation link i have provide.
Sudo is not a CLI command that is a Security Policy framework (like or not).
I try a summary:

Sudo is more a permission escalation and root is consider as UID=0. (i dont understand after all i explain why continue to confuse it)
that is really defferent...

We speak about execute a child process over setuid. < ------- THE TROUBLE IS HERE
And a Process on UNIX is a Program execute inside a environement. < ------- THE TROUBLE IS HERE

i can give you a exemple:
could you execute a helloSystem application over sudo ?

sudo Date and Time.app

normally it work only if you force -E and you should never as say on every sudo documentation.

I recommand you to read the manual. The actual approch is totaly worng. It dont exist any documenation it explain about put sudo inside the application . < ------- THAT APPROCHE IS INSECURE

When i'll finish Date and Time.app i totaly not make anything arround sudo.
I'll let you fixe sudo trouble by you self..

Without a True Sudo policy Date and Time.app will be the last application it require previllege escalation i'll touch.

I repeat not because i dont want.. That because i can't.

Regards

[Hierosme]

By know how work Sudo , that easy to understand, the application have to be start as child process for get privilege escalation over setuid.

Actually helloSystem application include call of sudo inside application code, that approche i worng and insecure...

then helloSystem application is design like that, and every documentation on the world recommend to not do thing like that.

[probonopd]

I am trying to keep everything simple and maintainable, but of course it should not be insecure by design.

Can you describe which changes would be needed in the system, outside of your applications (e.g., in /usr/local/etc/sudoers.d)?

Thank you.

[Hierosme]

Phooo you can't imagine how you are right.

Simple yes but not insecure by design i like a lot what you saying.

Trust me i'll do me best to help you in that direction.

It have different approch:

• security by USER
• security by COMMAND
• security by COMMAND GROUP <----- i use it on my exemple
• a mixe of that

From my point:
We can try a COMMAND approch and when our policies gain in maturity we'll can group them as COMMAND GROUP.

then my exemple focus in Date and Time.app:
Create a file /usr/local/etc/sudoers.d/date_and_time-sudoers

add it line:
%wheel ALL=(ALL) NOPASSWORD: FULL_PATH_TO_APPLICATION/Ressources/date_and_time.py

inside the starting script of the application:
exec sudo "FULL_PATH_TO_APPLICATION/Ressources/date_and_time.py" "$@"

What it doing:
If the user is part of wheel group (Traditional Unix admin) dont need password for change Date and time.
The user can simply start the Application and got auto escalation.
No need Apply button on that case

That is just a example, in fact Policies can be think globally, like a separte project, Here i focus on Date and Time.app, it certainlly not should get the north.

[Hierosme]

We can add security be specify full path of files it will be modify by the application. But that is a other story, we should found a valid simple way first then add complexity in a second step if need/require.

[probonopd]

We need to keep in mind that .app bundles can be freely moved around in the filesystem, they are not at one fixed path.

[Hierosme]

haaaaaaaaaa.

haaaaaaaaaaaa.

haaaaaaaaaaaaaaaaaa.

I understand that requirement. But it look like Sudo policies should care about that. Then the sudoers COMMAND options usage should be limited, and that a big part of the sudo Framework.

As you have identify the exemple i have provide work with a path in hard...

It let use only USER and GROUP , HOST approch, and exit COMMAND due to static path.

I´ll make a proof of concpet (unfortunally on GMU/Linux) and back with something it cover they user case:

• Totaly remove sudo usage inside the application
• No apply button need
• No password ask in loop
• No COMMAND Path in HARD

Normaly that is possible, if not i'll back to you and explain the border line limitation.

If Polkit is not a option Sudo limitation should be accepted for the moment ...

[probonopd]

helloSystem is made because we want a system that works more like a Mac. Being able to move around applications in the filesystem is central to that idea. I use this every day. For example, when I have multiple versions of an application.

[Hierosme]

I got it, but understand me, it havent been done by Apple arround Sudo, but arround something like Polkit.
We logicaly cant do more as feature provide by Sudo framework (And that all ready a lot).

Push the limit is my daily job ....

it will be hard, but not impossible.

In any case we can open a issue on Sudo git project and ask if it exist any feature for that.

[probonopd]

Isn't the whole /usr/local/etc/sudoers.d just so the user doesn't have to enter the password?
I would be fine with the user having to enter the password.

[Hierosme]

Traditionally under UNIX that is group name wheel, the better is the group.

Then if user utiliy have a Admin checkbox it should mean add user on the right group

[probonopd]

Yes. I am fine if only members of the wheel group can make changes, and need to enter their password.