lostutils / suex Goto Github PK

View Code? Open in Web Editor NEW

40.0 3.0 3.0 700 KB

execute commands as another user

License: MIT License

CMake 5.13% C++ 94.87%

sudo doas linux

suex's Introduction

Switch User Execute

A complete re-implementation of OpenBSD's doas that's extremely more robust

doas is a utility that is aimed to replace sudo for most ordinary use cases. Ted Unagst's, an OpenBSD developer, explained why He originally wrote it in his blog post: doas - dedicated openbsd application subexecutor.

The gist is that sudo is hard to configure and does a lot more then the standard user needs.

doas was created in order to replace sudo for regular folks like me and you.

Why Another Port?

doas only targets OpenBSD, and lacked features that I felt were missing from it and sudo as well.
Furthermore, all ports I looked at weren't production ready & poorly written.

Instead of creating my own port, I decided to re-write doas and create a new version that fixes the issues I care about.

Project Goals

Secure. User's must not be able to abuse the utility, and it should protect the user from making stupid mistakes.
Easy. The utility should be easy to audit, to maintain, to extend and to contribute to.
Friendly. Rule creation should be straight forward. Rule should be easy to understand and easy to debug.
Powerful. Rules should be short, concise and allow find-grained control.
Feature Parity. This project should have complete feature parity with the original utility.

To achieve these goals, the following design decisions were made:

The whole project was implemented in modern C++
Explicit is better then implicit (for instance, rule commands must be absolute paths)
Prefer using the standard library when possible - for the sake of security and maintainability.
Commands are globs, which allows to use the same rule for many executables.
Arguments are PCRE-compliant regular expressions, which allows to create fine-grained rules.

Getting started

pre-compiled .deb and .rpm packages are uploaded on each release.

Fedora

The project is currently available in a Copr:

$ sudo dnf copr enable odedlaz/suex
$ sudo dnf install -y suex

You can also build it from source:

$ git clone https://github.com/odedlaz/suex.git
$ sudo dnf install -y cmake pam-devel elfutils-devel rubygem-ronn gcc-c++
$ mkdir -p suex/build && cd suex/build && cmake .. && cd ..

Ubuntu

The project has a pre-compiled deb available at the release page.

You can also build it from source:

$ git clone https://github.com/odedlaz/suex.git
$ sudo apt install -y cmake libpam-dev libdw-dev ruby-ronn g++ rpm
$ mkdir -p suex/build && cd suex/build && cmake .. && cd ..

[!] A PPA is coming soon.

Arch

[!] coming soon...

Project Status

The project is in beta and will be until it reaches the 1.0 milestone.
I don't expect any major features to be added until then.

In order to reach 1.0 the project must:

get a good-enough unit & system test coverage.
pass a professional security audit.
have a continuous test & integration pipeline.
be available on major client distributions, i.e: Ubuntu, Fedora, Arch
have both an faq & examples page that have quality enough content in them

Authors

The main author is Oded Lazar

Contributions

I gladly accept contributions via GitHub pull requests.

If you are interested in contributing but not sure where to start, feel free to contact me.

Once I feel this method is not effective anymore, I'll probably open a slack / irc channel.

suex's People

Contributors

Stargazers

Watchers

Forkers

eclipseo vshan 2016rshah

suex's Issues

doas fails to parse doas.conf

When trying to edit doas.conf, it always fails to parse the command, despite them being valid:

DEBUG - parsing line 1: '# Welcome to doas!'
DEBUG - line 1 is a comment, skipping.
DEBUG - parsing line 2: 'permit persist :wheel'
DEBUG - couldn't parse: permit persist :wheel
ERROR - line invalid

Project name is misleading

Various users pointed out that the name doas conflicts with other projects and causes confusion.

Contenders

suexec
sux - I love that name, but it's already taken by a deprecated project. thoughts?
suex
runas - reuse my previous project's name. conflicts with the windows alternative.

Add usage demo

I believe that asciinema is the best way to go.

Add to AUR

I'd do it if I knew how, I might look into it tonight, but this would be very helpful.

thank you for all the hard work man.

Add a Fedora Copr

Add commit guards

guard commmit that don’t pass “cpplint”, which checks that code conforms to the style guide
guard commits that don’t pass tests
guard commits that weren’t linted by clang-format
guard commits that don’t pass audit tools

Consecutive spaces make config file invalid

When more than one blank is used to separate the entries of a line in the configuration file (e.g. to make it look more neat or clearly formatted) the configuration file is invalid.
Wouldn't it be better to allow any kind of whitespace as delimiter between the components of a line?

Conflict with identical username and group?

Does it cause a conflict if the username is identical to the group?

We have a group with some developers working on a service plus a generic account under which the service is running. The generic account has the same name as the group.

Problem description:
The following group configuration entry is in suex.conf.
permit nopass :foo as root cmd /usr/bin/systemctl args (status|restart|stop|start) nginx.service

It works for all members of the group, but not for the generic account foo .
% id
uid=316(foo) gid=253(foo) groups=253(foo),110(a),120(b),122(c),126(d),230(e),248(f),254(g),908(h)
% suex systemctl status nginx.service
You are not allowed to execute '/usr/bin/systemctl status nginx.service' as root

I have to add an additional username based configuration entry for foo to enable it as well:
permit nopass foo as root cmd /usr/bin/systemctl args (status|restart|stop|start) nginx.service

Only with this additional entry foo can suex the command, too.

Configuration can be altered between calls

Many code paths check that a file exists and then reads it.
There's a small window that allows an attacker to replace the file between these calls.

Replace non-standard file locks

suex forbids multiple instances from editing the configuration file.
The mechanism is a simple lock file that was created for this purpose.

We need to replace this ad-hoc solution with a proper locking mechanism.

Unit & System Tests are missing

Tests are crucial for a healthy, working, project.

following links can break some usage

suex follow links by default which causes issues when the target app uses the link to figure out which toggles to use.

for example, kmod uses the symbolic links lsmod,rmmod,insmod, etc' to do its magic.
Because suex follow links we get an unexpected behavior -

$ suex -V modprobe vboxdrv
DEBUG - Y .+ ~= /usr/bin/kmod vboxdrv

instead of:

$ suex -V modprobe vboxdrv
DEBUG - Y .+ ~= /usr/sbin/modprobe

Solution: instead of following links, use the absolute path.

Replace std::regex with re2

RE2 is Google's take on regex engines.
IMO, it's api is a bit cumbersome compared to std::regex but its considered safer then std::regex (which, as far as I know, based on boost::regex).

From WhyRE2:

Safety is RE2's raison d'être.
RE2 was designed and implemented with an explicit goal of being able to handle regular expressions from untrusted users without risk...

limit the length of each configuration line (and don’t load if they surpass it)
limit the length of commands and arguments
limit the amount of variables in “setenv”

Add an example configuration file on install

Auditing is missing

suex is missing an audit feature that'll give sysadmins insights into suex usage.
For example:

User was denied execution
User tried to run a specific command many times during a specific timeframe
User edited the configuration file

I believe that this information can be sent using rsyslog.

Things to point out:

This file can be read by anyone, but only the root user can edit it
Default configuration is important in this case