[Rack] Baron Security

Jonathan Lassoff jof at thejof.com
Tue Jan 22 19:40:13 UTC 2013


Yeah... I'm just realizing this after seeing the -discuss post.

:/ -- my bad.

So... I'm a bit perplexed as to why this doesn't work.

I've modified upstart to start the baron process as baron/barons, as
confirmed with strace:

`--> sudo strace -ff -q -e trace=fork,execve,setgid,setuid -p 1
[pid 18236] setgid(124)                 = 0
[pid 18236] setuid(31516)               = 0
[pid 18236] execve("/usr/local/share/baron/noisebridge-baron/baron.py",
["/usr/local/share/baron/noisebrid"..., "--codefile",
"/usr/local/share/baron/codes.txt", "--port", "/dev/ttyS5", "--logfile",
"/usr/local/share/baron/baron.log"], [/* 4 vars */]) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---

But this is then logging that:

ERROR   Serial port setup failed: /dev/ttyS5: <class
'serial.serialutil.SerialException'>: could not open port /dev/ttyS5:
[Errno 13] Permission denied: '/dev/ttyS5'

I think that user "baron" should have access to this by being in the
"dialout" group.

`--> id baron
uid=31516(baron) gid=100(users) groups=100(users),20(dialout),124(barons)

`--> ls -l /dev/ttyS5
crw-rw---- 1 root dialout 4, 69 Jan 22 11:37 /dev/ttyS5


I was going to say that maybe init / upstart needs to be re-started, but
minotaur rebooted while I wrote this mail! :p

`--> uptime
 11:39:51 up 2 min,  3 users,  load average: 0.21, 0.17, 0.07

On Tue, Jan 22, 2013 at 11:19 AM, Danny O'Brien <danny at spesh.com> wrote:

> Aha!
>
> Jof, could you fix your thing? It is borken -- the script doesn't have
> enough permissions to write to its own log (fixed) and ttySwhatever (which
> still needs to be fixed)
>
> d.
>
>
> On Tue, Jan 22, 2013 at 1:57 AM, Jonathan Lassoff <jof at thejof.com> wrote:
>
>> I was looking at baron on minotaur tonight and thought that some of the
>> permissions were a bit too open for the codes and log file.
>>
>> Maybe we should rotate or truncate the log after a while? Seems like
>> we're collecting info on users' comings and goings, and there's no real
>> reason to keep that forever.
>>
>>
>> I think we should use the existing "barons" group for allowing access to
>> modify the daemons state.
>>
>> So, I did:
>>
>> sudo chmod 0660 /usr/local/share/baron/codes.txt (owned by root / barons)
>> sudo chmod 0640 /usr/local/share/baron/baron.log (owned by root / root)
>>
>> The daemon is already running as root (lulz)
>>
>> `--> ps aux ...
>> USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
>> root         1  0.0  0.1  24596  2556 ?        Ss   Jan09   0:08
>> /sbin/init
>> [...snip...]
>> root      1637  0.0  0.5  56724 10656 ?        Ss   Jan09   0:27
>> /usr/bin/python /usr/local/share/baron/noisebridge-baron/baron.py
>> --codefile /usr/local/share/baron/codes.txt --port /dev/ttyS5 --logfile
>> /usr/local/share/baron/baron.log
>>
>> I added a baron user:
>>
>> sudo useradd -G barons --shell /bin/sh --home-dir /nonexistant
>> --no-create-home --no-user-group baron
>>
>> and then added a "setuid baron" and "setgid barons" line to
>> /etc/init/baron.conf
>>
>>
>>
>> I pushed this change and a readme to github as well:
>>
>>
>> https://github.com/noisebridge/noisebridge-baron/commit/29f4dc6003bdc876dd7b50c8c6ee2df75e1478a1
>>
>>
>> Now, I just need to figure out how to handle getting the daemon to reopen
>> logfiles in response to a signal, so logrotate can truncate cleanly.
>>
>> --j
>>
>> _______________________________________________
>> Rack mailing list
>> Rack at lists.noisebridge.net
>> https://www.noisebridge.net/mailman/listinfo/rack
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.noisebridge.net/pipermail/rack/attachments/20130122/d19eaf82/attachment-0003.html>


More information about the Rack mailing list