[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