Re: not exactly (Re: systrace removed? Why?)

[Michal Bozon]

if someone's interested, here a list of fs differences
between 6.0 upgraded from 5.9, and 6.0 install, i found,
with some obvious differences like smtpd spool or sysmerge
backups removed (amd64/qemu):

http://pastebin.com/raw/VPkdbvxy (text/plain)

(not pasting because of long lines)

hth

Re: not exactly (Re: systrace removed? Why?)

[Edgar Pettijohn]

Sent from my iPhone

On Sep 3, 2016, at 12:46 PM, Michal Bozon <mxl...@gmail.com> wrote:

>> good(?) news: sysmerge is gone in 6.0
>> but not removed by 5.9 to 6.0 uprade process.
> 
> s/sysmerge/systrace/
> 

pledge()

Re: not exactly (Re: systrace removed? Why?)

[Michal Bozon]

> > good(?) news: sysmerge is gone in 6.0
> > but not removed by 5.9 to 6.0 uprade process.
> > 
> 
> I really have a hard time understanding what you're trying to point out.
> 
> Yes, systrace is gone, but it's an ordinary binary that does no harm,
> feel free to remove it if it makes you feel better.
> 
> sysmerge isn't gone, but it is executed automatically if you use a
> bsd.rd upgrade, hence it's only mentioned in the manual upgrade process.

ok, never mind,
i have just spotted it when comparing fs trees of
freshly installed 6.0 and
freshly installed/upgraded 5.9/6.0

.. and made sure to report it immediately,
since the removal of systrace is advertised
as a security enhancement :)

Re: not exactly (Re: systrace removed? Why?)

[Michal Bozon]

> good(?) news: sysmerge is gone in 6.0
> but not removed by 5.9 to 6.0 uprade process.

s/sysmerge/systrace/

Re: not exactly (Re: systrace removed? Why?)

[Theo Buehler]

On Sat, Sep 03, 2016 at 05:37:22PM +, Michal Bozon wrote:
> > Why?
> 
> good(?) news: sysmerge is gone in 6.0
> but not removed by 5.9 to 6.0 uprade process.
> 

I really have a hard time understanding what you're trying to point out.

Yes, systrace is gone, but it's an ordinary binary that does no harm,
feel free to remove it if it makes you feel better.

sysmerge isn't gone, but it is executed automatically if you use a
bsd.rd upgrade, hence it's only mentioned in the manual upgrade process.

not exactly (Re: systrace removed? Why?)

[Michal Bozon]

> Why?

good(?) news: sysmerge is gone in 6.0
but not removed by 5.9 to 6.0 uprade process.

Re: systrace removed? Why?

[Christian Weisgerber]

On 2016-04-27, Marc Espie <es...@nerim.net> wrote:

> Race-conditiony things that make you go hum, oh shit is this thing
> more dangerous than what it's actually potecting. Plus semantic bugs.
> Like the time we had to hunt a really weird copy bug in the qt code until
> we realized it was just systrace fucking up.

Then there was the instance where a configure script would produce
a different result when run under systrace, causing a port to be
built differently.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: systrace removed? Why?

[Marc Espie]

There were some significant issues with systrace over the years.

Race-conditiony things that make you go hum, oh shit is this thing
more dangerous than what it's actually potecting. Plus semantic bugs.
Like the time we had to hunt a really weird copy bug in the qt code until
we realized it was just systrace fucking up.

Good riddance.

Re: systrace removed? Why?

[Kevin Chadwick]

> it is not important.
> 
> systrace was effectively deprecated 4-10 years ago, when there stopped
> being a maintainer for it, or the broken ecosystem surrounding.
> 
> That was a gap needed to consider a replacement model.
> 
> What do you want here?

I guess nothing important.

I am happy with pledge (I love it) as a replacement. I was simply
wondering what the potential dangers are for my web server that utilises
systrace on 5.9 along with newly pledged base processes and a few port
processes, currently it appears to be working fine, perhaps it's
performance has sufferred but I haven't noticed. I guess it takes
hundreds of syscalls to notice and I will simply switch to pledge when
performance requirements demand my time which I hope will happen within
6 months ;) . I already had plans to move to a potentially custom
pledged c binary (if my use case can be more restricted) and a nicer
and lighter system anyway.

So thanks for the hard work.

-- 

KISSIS - Keep It Simple So It's Securable

Re: systrace removed? Why?

[Theo de Raadt]

>> how do you mean? what happens on 5.9 when you use systrace with pledged
>> programs? Does cpu usage go through the roof by any chance? That would
>> explain why I have had to disable it to avoid waiting so long for
>> systraced desktop programs.
>
>hmmm, actually I guess the claws-mail port may not be pledged yet but
>cpu usage seemed to go through the roof on 5.9 anyways.

So it is just some theory you invented, without any facts?

Re: systrace removed? Why?

[Theo de Raadt]

>> > Unfortunately systrace overhead can be significant for monitoring
>> > complex programs but it could potentially be useful as a part of a
>> > (HIPS or system intrusion or malfunction detection for a secure
>> > server). hmmm, assuming pledge doesn't kill the offending process first,
>> > haha.  
>> 
>> systrace and pledge did not work together.  So that's balony.
>
>how do you mean? what happens on 5.9 when you use systrace with pledged
>programs? Does cpu usage go through the roof by any chance? That would
>explain why I have had to disable it to avoid waiting so long for
>systraced desktop programs.

it is not important.

systrace was effectively deprecated 4-10 years ago, when there stopped
being a maintainer for it, or the broken ecosystem surrounding.

That was a gap needed to consider a replacement model.

What do you want here?

Re: systrace removed? Why?

[Kevin Chadwick]

> how do you mean? what happens on 5.9 when you use systrace with pledged
> programs? Does cpu usage go through the roof by any chance? That would
> explain why I have had to disable it to avoid waiting so long for
> systraced desktop programs.

hmmm, actually I guess the claws-mail port may not be pledged yet but
cpu usage seemed to go through the roof on 5.9 anyways.

-- 

KISSIS - Keep It Simple So It's Securable

Re: systrace removed? Why?

[Kevin Chadwick]

> > Unfortunately systrace overhead can be significant for monitoring
> > complex programs but it could potentially be useful as a part of a
> > (HIPS or system intrusion or malfunction detection for a secure
> > server). hmmm, assuming pledge doesn't kill the offending process first,
> > haha.  
> 
> systrace and pledge did not work together.  So that's balony.

how do you mean? what happens on 5.9 when you use systrace with pledged
programs? Does cpu usage go through the roof by any chance? That would
explain why I have had to disable it to avoid waiting so long for
systraced desktop programs.

Thanks

-- 

KISSIS - Keep It Simple So It's Securable

Re: systrace removed? Why?

[Theo de Raadt]

> > I guess the question is: how many people actually use systrace in
> > scripts? Probably very very few.

>From yesterday onwards, noone uses it.

> I use it in scripts but will look to switching to pledge when I
> have time, which I *should* be able to find in the next 6 months, haha.
> It is however sometimes insightful as a quick and dirty debugging tool.

If you stick to old code, sure.

> Unfortunately systrace overhead can be significant for monitoring
> complex programs but it could potentially be useful as a part of a
> (HIPS or system intrusion or malfunction detection for a secure
> server). hmmm, assuming pledge doesn't kill the offending process first,
> haha.

systrace and pledge did not work together.  So that's balony.

> I guess pledging /bin/sh may throw up challenges too though I see many
> pledges in csh?

sh is pledged.

> and so is systrace useful there?

systrace was removed, so how can it be useful?

Re: systrace removed? Why?

[Kevin Chadwick]

> I guess the question is: how many people actually use systrace in
> scripts? Probably very very few.

I use it in scripts but will look to switching to pledge when I
have time, which I *should* be able to find in the next 6 months, haha.
It is however sometimes insightful as a quick and dirty debugging tool.

Unfortunately systrace overhead can be significant for monitoring
complex programs but it could potentially be useful as a part of a
(HIPS or system intrusion or malfunction detection for a secure
server). hmmm, assuming pledge doesn't kill the offending process first,
haha.

I guess pledging /bin/sh may throw up challenges too though I see many
pledges in csh? and so is systrace useful there?

-- 

KISSIS - Keep It Simple So It's Securable

Re: systrace removed? Why?

[Stuart Henderson]

On 2016-04-26, arrowscr...@mail.com  wrote:
> Of course, you can put it on packages

Nope.

Re: systrace removed? Why?

[Michael McConville]

arrowscr...@mail.com wrote:
> I know about the pledge(2) development, but systrace and pledge are
> not mutually exclusive. Pledge need to be used inline, where systrace
> can be used as a command line tool. 
> 
> If you remove it, many scripts that use systrace for privilege
> reduction will broke.

I guess the question is: how many people actually use systrace in
scripts? Probably very very few.

> Of course, you can put it on packages, but if you follow this logic,
> shouldn't other tools be also removed and be on packages? banner(1)
> for example, is kind useless. The cpan(1) pkg manager from perl also
> could be in packages. Same with sqlite3, I think. Or telnet, since
> almost no one uses it anymore. Etc.

I'm pretty sure that you can't package systrace because it needs to be
supported by the kernel. I expect that that's part of the reason why it
was removed: axing it simplifies and quickens the kernel.

Re: systrace removed? Why?

[arrowscript]

I know about the pledge(2) development, but systrace and pledge are not 
mutually exclusive. Pledge need to be used inline, where systrace can be used 
as a command line tool. 
If you remove it, many scripts that use systrace for privilege reduction will 
broke.
Of course, you can put it on packages, but if you follow this logic, shouldn't 
other tools be also removed and be on packages? banner(1) for example, is kind 
useless. The cpan(1) pkg manager from perl also could be in packages. Same with 
sqlite3, I think. Or telnet, since almost no one uses it anymore. Etc.

Re: systrace removed? Why?

[Luis Coronado]

Why not? In a more serious way, read misc@ and tech@ particuarly in the
subject about pledge.

-luis

On Monday, 25 April 2016,  wrote:

> Why?

systrace removed? Why?

[arrowscript]

Why?

Re: "# systrace -c1000:1000 kate" for privilege escalated editing?

[Stuart Henderson]

On 2015-12-03, Luke Small <lukensm...@gmail.com> wrote:
> I want to be able to use systrace for privilege escalation for kompare for
> sysmerge diffs and kate. Why isn't systrace able to do this?

I can't quite figure out what you're trying to do, but running big
GUI programs and libraries with root privileges (whether that's from
systrace or doas or sudo or su or whatever) is usually not a good idea.

Re: "# systrace -c1000:1000 kate" for privilege escalated editing?

[Luke Small]

>I can't quite figure out what you're trying to do, but running big GUI
>programs and libraries with root privileges (whether that's from systrace
or >doas or sudo or su or whatever) is usually not a good idea.

Thinking about it now, I guess if you add root write privileges to writing
files, you add it to the whole X system that is governing the Kate, kdiff,
or kompare. It would probably be worth just having a script read the root
owned file into a temporary file operating on it and doing doas to copy it
to the original file location. I just want the fine grained control that
diff doesn't seem to offer. And I hate vi.

<icepic...@gmail.com>

>
> <lukensm...@gmail.com>

Re: "# systrace -c1000:1000 kate" for privilege escalated editing?

[Janne Johansson]

2015-12-04 0:10 GMT+01:00 Luke Small :

> There must be some sort of kernel lock, because if you su - twice into the
> 1000 user, it won't open a x window either! I'm sure there is a
> conservative security policy at play,


X and switching users requires you to read up on xauth, always has.


-- 
May the most significant bit of your life be positive.

Re: "# systrace -c1000:1000 kate" for privilege escalated editing?

[Luke Small]

There must be some sort of kernel lock, because if you su - twice into the
1000 user, it won't open a x window either! I'm sure there is a
conservative security policy at play, and maybe writing a script to copy
write and doas cp will work, but it also doesn't work if I want to write a
program that doesn't suid but can open a privileged socket under systrace
-c 1000:1000 ./server
On Dec 2, 2015 19:44, "Vadim Zhukov" <persg...@gmail.com> wrote:

> 03 дек. 2015 г. 4:27 пользователь "Luke Small"
<lukensm...@gmail.com>
> написал:
> >
> > I want to be able to use systrace for privilege escalation for kompare
> for
> > sysmerge diffs and kate. Why isn't systrace able to do this?
>
> Because noone wrote a systrace policy for Kate and Kompare (for your
> installation and user) yet? That's without mentioning that it would be hard
> to restrict those applications in a correct manner: they do use a lot of
> system resources by just being nice KDE apps.
>
> That being said, I won't expect much security problems in Kompare itself.
> Kate is more complex, but still doesn't run in terminal. Thus Kompare and
> Kate likely not being hurt by some crazy escape codes in patch files.
> Anything else lies outside of usage profile you're talking about, if I
> understood you correctly.
>
> --
> Vadim Zhukov

"# systrace -c1000:1000 kate" for privilege escalated editing?

[Luke Small]

I want to be able to use systrace for privilege escalation for kompare for
sysmerge diffs and kate. Why isn't systrace able to do this?


-Luke

Re: "# systrace -c1000:1000 kate" for privilege escalated editing?

[Vadim Zhukov]

03 дек. 2015 г. 4:27 пользователь "Luke Small"
<lukensm...@gmail.com>
написал:
>
> I want to be able to use systrace for privilege escalation for kompare for
> sysmerge diffs and kate. Why isn't systrace able to do this?

Because noone wrote a systrace policy for Kate and Kompare (for your
installation and user) yet? That's without mentioning that it would be hard
to restrict those applications in a correct manner: they do use a lot of
system resources by just being nice KDE apps.

That being said, I won't expect much security problems in Kompare itself.
Kate is more complex, but still doesn't run in terminal. Thus Kompare and
Kate likely not being hurt by some crazy escape codes in patch files.
Anything else lies outside of usage profile you're talking about, if I
understood you correctly.

--
Vadim Zhukov

Re: tame(2) will by pass systrace rules

[Sebastien Marie]

On Sun, Sep 20, 2015 at 03:28:41PM +0800, johnw wrote:
> Hi all,
> 
> I run my program will systrace, I noticed the program can by pass systrace,
> If I add the tame(2) call to my program.
> 

Hi John,

Yes, it is the expected behaviour than when a program call tame(2),
systrace(4) usage in this program is skipped. You couldn't use
systrace(4) and tame(2) in the same program.

The tame(2) documentation don't have this information. I will see to add
it.

Thanks.
-- 
Sebastien Marie

tame(2) will by pass systrace rules

[johnw]

Hi all,

I run my program will systrace, I noticed the program can by pass 
systrace, If I add the tame(2) call to my program.


my program will connect to inet, if I run my program will systrace, I 
need to add systrace rule like this "native-connect:  permit",
I noticed, if I add the tame("inet", NULL) call before connect to inet, 
I can connect to inet, even do not need to add systrace 
rule(native-connect: XXX permit" without any error.


Thanks.

Re: Don't forget systrace Was: running multiple simultaneous X sessions as different users

[luke350]

On 03/22/15 07:44, Kevin Chadwick wrote:

Systrace is also an option but the policy writing could be a little
work, the regex support is certainly helpful there.

systrace -A is very helpful

Excellent info; thanks.  (This list has the
highest signal/noise ratio among tech lists that
come to mind.)

For now I'll try ssh -X user, umask 0077 for all users
including root (though I learned the hard way you have to
relax that before doing pkg_add...), and keep all this other
material as reference for when I can do more or want to
try things more like systrace, xauth etc (or non-drm video
driver etc to get more screens recognized by X).

That is, unless I learn that there are still ways for one
user to view another's data etc, when I do just that much.
Corrections to my thinking are welcomed.

(This effort is so impressive.  Especially compared to
so many other situations where if it seems to work on
the surface, even smart people call it good  move
on. It seems like the worst problems now could be hardware
security, which seems very hard, and 3rd-party systems.
And general human behavior but we can keep trying there
too.)

Best regards,

Luke

Re: Don't forget systrace Was: running multiple simultaneous X sessions as different users

[Kevin Chadwick]

On Sat, 21 Mar 2015 14:14:22 -0700
luke...@onemodel.org wrote:

 Thanks to all who've commented: this has been educational  useful.

Systrace is also an option but the policy writing could be a little
work, the regex support is certainly helpful there.

systrace -A is very helpful
then edit files in .systrace such as removing lib version numbers to
prevent upgrades from breaking the policy and adding regex for IP
connections

systrace -a to enforce.

Personally I'd like to use systrace -A with cksum -a sha256 on the
updated policy file and gxmessage to warn about previously unseen
behaviour but unfortunately I don't think the policy generation has any
regex support so every IP connected to will be logged and flag up new
behavior and I think the -E logging option will only help in
enforcement mode. There used to be a gui mode which I believe Ted
removed without any objections but was quite cool and would enforce but
ask you upon new system calls but it would very occasionally get stuck
during the deny while asking stage and so cause user complaints
(here, not on list).

chflags sappnd might work too on the policy files making a pretty good
yet trouble free HIPS but I haven't tested that yet

systrace

[Dan Becker]

asking for a friend

Is the systrace policy format fully documented anywhere? There's a quick
explanation on systrace(1) but there's no dedicated page for the format


-- 
--Dan

Re: systrace

[Ted Unangst]

On Wed, Dec 24, 2014 at 09:12, Dan Becker wrote:
 asking for a friend
 
 Is the systrace policy format fully documented anywhere? There's a quick
 explanation on systrace(1) but there's no dedicated page for the format

The explanation may be quick, but as far as i know it is also complete.

Re: linux port of systrace

[Илья Аржанников]

On May 14, 2014, at 10:49, Philip Guenther guent...@gmail.com wrote:

 On Tue, May 13, 2014 at 8:06 AM, Илья Аржанников
iarzhanni...@gmail.com wrote:
 I am trying to use linux port systrace. And I found the problem. When I run
under systrace (it does not matter with -A or -a (actually it never came till
-a)) something that use vfork systrace and children processes hangup. I saw in
sources that linux port uses ptrace as backend because it's not a native
systrace subsystem. And linux systrace try to rewrite vfork system call on
sys_clone, but it give nothing. With fork everything is ok, because fork is
wrap around clone syscall and systrace just add one more flag to call it.

 Has anyone experience this problem?

 This isn't too surprising: vfork() is defined as stopping the parent process
until the child exits or execs, but ptrace() works by reparenting the target
process, so the child that you're supposed to block for isn't yours anymore.
Rewriting vfork() into a clone() call isn't any easier: Linux follows the
original semantics which preserve the the exact stack contents and registers.
That's why on some Linux archs vfork() is a syscall and not just a wrapper of
clone(): clone() has so many args that it requires stack manipulations that
vfork() can't do.

 Stepping back, I would suggest you look at what native control subsystems
are offered by Linux that might do what you need to do.  For example, can your
problem be solved with SELinux?

 (systrace is only used in the OpenBSD base for some ports building work and
for sshd privsep sandboxing... but as soon as I or someone else comes up with
a simpler replacement for it for those functions, it'll be removed.)


 Philip Guenther

Hi. I fixed hangup on vfork syscall. But now when child process that was
vforked calls exec* function ptrace return user_regs_struct (after call
ptrace(PTRACE_GETREGS, ...)) with rdi rsi rdx rcx r8 r9 register equal to 0
(zero). How it could be?

linux port of systrace

[Илья Аржанников]

Hello.

I am trying to use linux port systrace. And I found the problem. When I run 
under systrace (it does not matter with -A or -a (actually it never came till 
-a)) something that use vfork systrace and children processes hangup. I saw in 
sources that linux port uses ptrace as backend because it's not a native 
systrace subsystem. And linux systrace try to rewrite vfork system call on 
sys_clone, but it give nothing. With fork everything is ok, because fork is 
wrap around clone syscall and systrace just add one more flag to call it. 

Has anyone experience this problem?

Re: linux port of systrace

[Vadim Zhukov]

2014-05-13 19:06 GMT+04:00 Илья Аржанников iarzhanni...@gmail.com:
 Hello.

 I am trying to use linux port systrace. And I found the problem. When I run 
 under systrace (it does not matter with -A or -a (actually it never came till 
 -a)) something that use vfork systrace and children processes hangup. I saw 
 in sources that linux port uses ptrace as backend because it's not a native 
 systrace subsystem. And linux systrace try to rewrite vfork system call on 
 sys_clone, but it give nothing. With fork everything is ok, because fork is 
 wrap around clone syscall and systrace just add one more flag to call it.

 Has anyone experience this problem?

Does this also happen with only one CPU?

--
  WBR,
  Vadim Zhukov

Re: linux port of systrace

[Илья Аржанников]

On May 13, 2014, at 21:13, Vadim Zhukov persg...@gmail.com wrote:

 2014-05-13 19:06 GMT+04:00 Илья Аржанников iarzhanni...@gmail.com:
 Hello.
 
 I am trying to use linux port systrace. And I found the problem. When I run 
 under systrace (it does not matter with -A or -a (actually it never came 
 till -a)) something that use vfork systrace and children processes hangup. I 
 saw in sources that linux port uses ptrace as backend because it's not a 
 native systrace subsystem. And linux systrace try to rewrite vfork system 
 call on sys_clone, but it give nothing. With fork everything is ok, because 
 fork is wrap around clone syscall and systrace just add one more flag to 
 call it.
 
 Has anyone experience this problem?
 
 Does this also happen with only one CPU?
Not applicable, I'm already trying it under virtual box with one cpu.  And on 
dedicated server with core-i7. 
 --
  WBR,
  Vadim Zhukov

Re: linux port of systrace

[Илья Аржанников]

 = 262144
net.ipv6.ip6frag_low_thresh = 196608
net.ipv6.ip6frag_time = 60
net.ipv6.route.gc_thresh = 1024
net.ipv6.route.max_size = 4096
net.ipv6.route.gc_min_interval = 0
net.ipv6.route.gc_timeout = 60
net.ipv6.route.gc_interval = 30
net.ipv6.route.gc_elasticity = 0
net.ipv6.route.mtu_expires = 600
net.ipv6.route.min_adv_mss = 1
net.ipv6.route.gc_min_interval_ms = 500
net.ipv6.icmp.ratelimit = 1000
net.ipv6.bindv6only = 0
net.ipv6.nf_conntrack_frag6_timeout = 60
net.ipv6.nf_conntrack_frag6_low_thresh = 196608
net.ipv6.nf_conntrack_frag6_high_thresh = 262144
net.ipv6.ip6frag_secret_interval = 600
net.ipv6.mld_max_msf = 64
net.nf_conntrack_max = 15692
net.unix.max_dgram_qlen = 10
abi.vsyscall32 = 1
crypto.fips_enabled = 0


On May 13, 2014, at 21:37, Илья Аржанников iarzhanni...@gmail.com wrote:

 
 On May 13, 2014, at 21:13, Vadim Zhukov persg...@gmail.com wrote:
 
 2014-05-13 19:06 GMT+04:00 Илья Аржанников iarzhanni...@gmail.com:
 Hello.
 
 I am trying to use linux port systrace. And I found the problem. When I run 
 under systrace (it does not matter with -A or -a (actually it never came 
 till -a)) something that use vfork systrace and children processes hangup. 
 I saw in sources

Re: linux port of systrace

[Philip Guenther]

On Tue, May 13, 2014 at 8:06 AM, Илья Аржанников
iarzhanni...@gmail.comwrote:

 I am trying to use linux port systrace. And I found the problem. When I
 run under systrace (it does not matter with -A or -a (actually it never
 came till -a)) something that use vfork systrace and children processes
 hangup. I saw in sources that linux port uses ptrace as backend because
 it's not a native systrace subsystem. And linux systrace try to rewrite
 vfork system call on sys_clone, but it give nothing. With fork everything
 is ok, because fork is wrap around clone syscall and systrace just add one
 more flag to call it.

 Has anyone experience this problem?


This isn't too surprising: vfork() is defined as stopping the parent
process until the child exits or execs, but ptrace() works by reparenting
the target process, so the child that you're supposed to block for isn't
yours anymore.  Rewriting vfork() into a clone() call isn't any easier:
Linux follows the original semantics which preserve the the exact stack
contents and registers.  That's why on some Linux archs vfork() is a
syscall and not just a wrapper of clone(): clone() has so many args that it
requires stack manipulations that vfork() can't do.

Stepping back, I would suggest you look at what native control subsystems
are offered by Linux that might do what you need to do.  For example, can
your problem be solved with SELinux?

(systrace is only used in the OpenBSD base for some ports building work and
for sshd privsep sandboxing... but as soon as I or someone else comes up
with a simpler replacement for it for those functions, it'll be removed.)


Philip Guenther

Re: how to use the new rc.d system to start the daemon with systrace?

[Ingo Schwarze]

Stuart Henderson wrote on Fri, Oct 21, 2011 at 10:17:11AM +:
 On 2011-10-21, johnw johnw.m...@gmail.com wrote:

 after upgrade to current, now /etc/rc use the new rc.d system.
 my question is how to start the daemon(ntpd, named etc ..) with systrace?
 before upgrade to new rc.d system, i can edit /etc/rc like this

 echo 'starting named'; named $named_flags
 to
 echo 'starting named'; systrace -Ua named $named_flags

 any idea? thank you.

 it would be *possible* to do something like this and set named_systrace=YES
 in rc.conf.local, but I don't know if we want to go down that route,
 systrace isn't very widely used for daemons..

On first sight, i don't like the idea, it looks like a knob
for very little gain, if any.

The systrace facility is definitely useful for development
purposes, for example, to make sure that a port doesn't scribble
outside the proper directories.

However, is systrace really a tool to enforce security policies
in production?  I don't think that's what i heard people say.


 Index: rc.subr
 ===
 RCS file: /cvs/src/etc/rc.d/rc.subr,v
 retrieving revision 1.55
 diff -u -p -r1.55 rc.subr
 --- rc.subr   15 Oct 2011 16:05:15 -  1.55
 +++ rc.subr   21 Oct 2011 10:13:33 -
 @@ -44,7 +44,7 @@ rc_rm_runfile() {
  }
  
  rc_start() {
 - ${rcexec} ${daemon} ${daemon_flags} ${_bg}
 + ${rcexec} ${rcsystrace} ${daemon} ${daemon_flags} ${_bg}
  }
  
  rc_check() {
 @@ -183,6 +183,7 @@ _RC_RUNFILE=${_RC_RUNDIR}/${_name}
  
  eval _rcflags=\${${_name}_flags}
  eval _rcuser=\${${_name}_user}
 +eval _rcsystrace=\${${_name}_systrace}
  
  getcap -f /etc/login.conf ${_name} 1/dev/null 21  \
   daemon_class=${_name}
 @@ -193,8 +194,10 @@ getcap -f /etc/login.conf ${_name} 1/de
  [ -n ${_RC_FORCE} ]  [ X${_rcflags} = XNO ]  unset _rcflags
  [ -n ${_rcflags} ]  daemon_flags=${_rcflags}
  [ -n ${_rcuser}  ]  daemon_user=${_rcuser}
 +[ -n ${_rcsystrace} ]  [ X${_rcsystrace} = XYES ] || unset 
 _rcsystrace
  
  daemon_flags=$(printf ' %s' ${daemon_flags})
  daemon_flags=${daemon_flags## }
  pexp=${daemon}${daemon_flags:+ ${daemon_flags}}
  rcexec=su -l -c ${daemon_class} -s /bin/sh ${daemon_user} -c
 +[ -n ${_rcsystrace} ]  rcsystrace=/bin/systrace -Ua

Re: how to use the new rc.d system to start the daemon with systrace?

[Stuart Henderson]

On 2011-10-21, johnw johnw.m...@gmail.com wrote:
 after upgrade to current, now /etc/rc use the new rc.d system.
 my question is how to start the daemon(ntpd, named etc ..) with systrace?
 before upgrade to new rc.d system, i can edit /etc/rc like this

 echo 'starting named'; named $named_flags
 to
 echo 'starting named'; systrace -Ua named $named_flags

 any idea? thank you.



it would be *possible* to do something like this and set named_systrace=YES
in rc.conf.local, but I don't know if we want to go down that route, systrace
isn't very widely used for daemons..

Index: rc.subr
===
RCS file: /cvs/src/etc/rc.d/rc.subr,v
retrieving revision 1.55
diff -u -p -r1.55 rc.subr
--- rc.subr 15 Oct 2011 16:05:15 -  1.55
+++ rc.subr 21 Oct 2011 10:13:33 -
@@ -44,7 +44,7 @@ rc_rm_runfile() {
 }
 
 rc_start() {
-   ${rcexec} ${daemon} ${daemon_flags} ${_bg}
+   ${rcexec} ${rcsystrace} ${daemon} ${daemon_flags} ${_bg}
 }
 
 rc_check() {
@@ -183,6 +183,7 @@ _RC_RUNFILE=${_RC_RUNDIR}/${_name}
 
 eval _rcflags=\${${_name}_flags}
 eval _rcuser=\${${_name}_user}
+eval _rcsystrace=\${${_name}_systrace}
 
 getcap -f /etc/login.conf ${_name} 1/dev/null 21  \
daemon_class=${_name}
@@ -193,8 +194,10 @@ getcap -f /etc/login.conf ${_name} 1/de
 [ -n ${_RC_FORCE} ]  [ X${_rcflags} = XNO ]  unset _rcflags
 [ -n ${_rcflags} ]  daemon_flags=${_rcflags}
 [ -n ${_rcuser}  ]  daemon_user=${_rcuser}
+[ -n ${_rcsystrace} ]  [ X${_rcsystrace} = XYES ] || unset _rcsystrace
 
 daemon_flags=$(printf ' %s' ${daemon_flags})
 daemon_flags=${daemon_flags## }
 pexp=${daemon}${daemon_flags:+ ${daemon_flags}}
 rcexec=su -l -c ${daemon_class} -s /bin/sh ${daemon_user} -c
+[ -n ${_rcsystrace} ]  rcsystrace=/bin/systrace -Ua

how to use the new rc.d system to start the daemon with systrace?

[johnw]

after upgrade to current, now /etc/rc use the new rc.d system.
my question is how to start the daemon(ntpd, named etc ..) with systrace?
before upgrade to new rc.d system, i can edit /etc/rc like this

echo 'starting named'; named $named_flags
to
echo 'starting named'; systrace -Ua named $named_flags

any idea? thank you.

systrace(4) and openssh

[Peter J. Philipp]

The new systrace in openssh is great.  Good work djm!  How would someone go
about putting that into inetd?  Since inetd is only 1 root process you can't
attach a child to it.  Can you just make a policy without attaching a child
process?

-peter

Re: systrace

[Duncan Patton a Campbell]

On Wed, 15 Jul 2009 09:57:33 -0600
Bob Beck b...@obtuse.com wrote:

   Now it's not to say that *theoretically* systrace can't be a help.
 I'm certain it could if you knew 100% what you were doing and knew the
 inside and outs of the code.  but really that's a job for the
 developers, not the sysadmin running it. If the developer is going to
 do it, well, at that point your best bet is simply to privsep the code
 properly - that has been show to actually work, and doesn't require
 insanity on the part of the system admin to pull wild guesses out of
 his ass about what system calls this should use and why and when and
 what the impact of allowing something is. 
 

Systrace is a development/test tool that has been miscast.  In a
corporate/collective environment this would be a useful testbed
tool to validate programmer claims.  This would NOT be part of
the delivered product but maintained in a lab as part of an
automated sw test cycle.  Do I detect here a problem involved in
GPL-thinking?  It does tend to require that end users be delivered
of reams of Makefiles and other coder desiderata... why not
test tools too? ... and while we're at it ...

Dhu

Re: systrace

[Anton Karpov]

According to Provos's blog,
http://www.provos.org/index.php?/archives/34-Evading-System-Sandbox-Containment.html

The initial prototype of Systrace as described in the
paperhttp://www.citi.umich.edu/u/provos/papers/systrace.pdfavoided
this problem by using a look-aside buffer in the kernel. This
imposes a slight performance penalty but I hope that this obvious solution
is going to be included in the OpenBSD and NetBSD kernel soon.

But we have no idea about was this solution included into OpenBSD sources
tree or not...


2009/7/14 Theo de Raadt dera...@cvs.openbsd.org

  I've just been pondering,... were the systrace issues identified with in:
  http://it.slashdot.org/it/07/08/09/138224.shtml
  ever delt with and corrected?

 They were not identified there.  They were documented in the manual page
 right from the start.

  If so where can I find some more info on the fixes made?

 No, it isn't fixed.

Re: systrace

[Ross Cameron]

On Wed, Jul 15, 2009 at 9:21 AM, Anton Karpovtoxah...@gmail.com wrote:
 According to Provos's blog,

http://www.provos.org/index.php?/archives/34-Evading-System-Sandbox-Containme
nt.html

 The initial prototype of Systrace as described in the paper avoided this
 problem by using a look-aside buffer in the kernel. This imposes a slight
 performance penalty but I hope that this obvious solution is going to be
 included in the OpenBSD and NetBSD kernel soon.

 But we have no idea about was this solution included into OpenBSD sources
 tree or not...

Anyone got any thoughts on how hard implimenting said look aside
buffer would be?
Id love to do it myself but Ive not spent much time poking around in
oBSD kernel land.

 They were not identified there. B They were documented in the manual page
 right from the start.

Forgot to check there sorry, had a lazy moment.



--
Opportunity is most often missed by people because it is dressed in
overalls and looks like work.
Thomas Alva Edison
Inventor of 1093 patents, including:
The light bulb, phonogram and motion pictures.

Re: systrace

[Bob Beck]

* Ross Cameron ross.came...@linuxpro.co.za [2009-07-15 03:19]:
 On Wed, Jul 15, 2009 at 9:21 AM, Anton Karpovtoxah...@gmail.com wrote:
  According to Provos's blog,
 
 http://www.provos.org/index.php?/archives/34-Evading-System-Sandbox-Containme
 nt.html
 
  The initial prototype of Systrace as described in the paper avoided this
  problem by using a look-aside buffer in the kernel. This imposes a slight
  performance penalty but I hope that this obvious solution is going to be
  included in the OpenBSD and NetBSD kernel soon.
 
  But we have no idea about was this solution included into OpenBSD sources
  tree or not...
 
 Anyone got any thoughts on how hard implimenting said look aside
 buffer would be?
 Id love to do it myself but Ive not spent much time poking around in
 oBSD kernel land.
 

Relatively difficult and invasive but not impossible.

Now, you wanna know why we're probably not looking at it? Nobody is
interested. Wanna know why? Most of us don't believe systrace is a be
all and end all security tool. Most of us who work in the kernel do
not want to go to the trouble and disruption in the kernel to try to
fix something that in our opinion is broken by design. 

Why do I say it is broken by design? It's *too complicated*. For a
regular user to set it up it requires too much twiddling of the
policy, particularly to open it up and make a real daemon work within
it, so I'm relatively certain that 99% of the sysadmins who would use
it and deploy it have to use a policy that allows enough stuff so that
it really doesn't matter that they are using it - By comparison, I've
seen sysadmins trying to set up apache with PERL CHROOTED into an
apache chroot so they can run fully functional perl CGI stuff within
the chroot (so why bother in the first place!).  It's kind of like
having a maximum security prison but you have to give the inmates
ak-47's and ladders anyway... 

Now it's not to say that *theoretically* systrace can't be a help.
I'm certain it could if you knew 100% what you were doing and knew the
inside and outs of the code.  but really that's a job for the
developers, not the sysadmin running it. If the developer is going to
do it, well, at that point your best bet is simply to privsep the code
properly - that has been show to actually work, and doesn't require
insanity on the part of the system admin to pull wild guesses out of
his ass about what system calls this should use and why and when and
what the impact of allowing something is. 

So short answer, I think in theory it's a neat thing. in practice, 
it's not practical, and is not a magic bullet to allow you to run horrible
things securtly. 

-Bob

Re: systrace

[Ross Cameron]

I've just been pondering,... were the systrace issues identified with in:
http://it.slashdot.org/it/07/08/09/138224.shtml
ever delt with and corrected?

If so where can I find some more info on the fixes made?

Many thanks...

Re: systrace

[Theo de Raadt]

 I've just been pondering,... were the systrace issues identified with in:
 http://it.slashdot.org/it/07/08/09/138224.shtml
 ever delt with and corrected?

They were not identified there.  They were documented in the manual page
right from the start.

 If so where can I find some more info on the fixes made?

No, it isn't fixed.

Re: systrace insecure [was: Re: chroot browser]

[Edd Barrett]

Howdy,

On Thu, Mar 26, 2009 at 09:12:42AM -0600, Theo de Raadt wrote:
 That said, this is not enough reason to entirely delete the code.  It
 still has uses.

It's useful for checking ports are not dumping junk all over the
file-system. Please keep it.

Best Regards

Edd Barrett
(Freelance software developer / technical writer / open-source developer)

http://students.dec.bmth.ac.uk/ebarrett

Re: systrace insecure [was: Re: chroot browser]

[Niels Provos]

On Thu, Mar 26, 2009 at 8:23 AM, Jonathan Schleifer
js-openbsd-m...@webkeks.org wrote:
 It was removed when I reported a bug in NETBSD-5-0 that would crash
 the Kernel when you tried to use systrace. Instead of fixing that,
 they removed it.

Looks like you will have to run OpenBSD then.   For my personal use, I
find systrace quite helpful and the TOCTOU issues are hardly as black
and white as some people make you believe.

Niels.

systrace insecure [was: Re: chroot browser]

[Jonathan Schleifer]

Am 26.03.2009 um 07:17 schrieb Tobias Weisserth:

 I guess you should take a look at Systrace:
 http://en.wikipedia.org/wiki/Systrace


This was removed from NetBSD some time ago because it is vulnerable.  
They said it's not only possible to circumvent it, but also gain root  
using it. Is this fixed in OpenBSD somehow?

--
Jonathan

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of PGP.sig]

Re: systrace insecure [was: Re: chroot browser]

[Theo de Raadt]

  I guess you should take a look at Systrace:
  http://en.wikipedia.org/wiki/Systrace
 
 
 This was removed from NetBSD some time ago because it is vulnerable.  
 They said it's not only possible to circumvent it, but also gain root  
 using it. Is this fixed in OpenBSD somehow?

They freaked out and did the wrong thing.

systrace has a small problem.  It is a very difficult problem to fix
because of the kernel system call argument fetching is spread so
widely.  This problem was documented since the beginning:

BUGS
 Applications that use clone()-like system calls to share the complete ad-
 dress space between processes may be able to replace system call argu-
 ments after they have been evaluated by systrace and escape policy en-
 forcement.

That said, this is not enough reason to entirely delete the code.  It
still has uses.  With the other address space security changes we have
made, the risks from this are subtantially mitigated.  You also cannot
gain root except in extremely well crafted situations which are not
real; systrace does have the ability to grant root unless you build
the policy specifically to do such a stupid thing (actually, I am not
certain if our systrace, the original, ever had that deluded ability
of escalation; I think it was added by netbsd).

So a project that does zero about real security issues overreacted --
probably because the code had originally come from here.  Typical.
One can only hope that some issue comes up in openssh, and that they
then delete openssh, too.

Re: systrace insecure [was: Re: chroot browser]

[Jonathan Schleifer]

Am 26.03.2009 um 16:12 schrieb Theo de Raadt:

 They freaked out and did the wrong thing.

It was removed when I reported a bug in NETBSD-5-0 that would crash  
the Kernel when you tried to use systrace. Instead of fixing that,  
they removed it.

 systrace has a small problem.  It is a very difficult problem to fix
 because of the kernel system call argument fetching is spread so
 widely.  This problem was documented since the beginning:

 BUGS
 Applications that use clone()-like system calls to share the  
 complete ad-
 dress space between processes may be able to replace system call  
 argu-
 ments after they have been evaluated by systrace and escape  
 policy en-
 forcement.

This sounds really hard to exploit, indeed.

 That said, this is not enough reason to entirely delete the code.  It
 still has uses.  With the other address space security changes we have
 made, the risks from this are subtantially mitigated.  You also cannot
 gain root except in extremely well crafted situations which are not
 real; systrace does have the ability to grant root unless you build
 the policy specifically to do such a stupid thing (actually, I am not
 certain if our systrace, the original, ever had that deluded ability
 of escalation; I think it was added by netbsd).

I couldn't really believe that you can gain root when the application  
you systrace isn't running as root. Thanks for clarifying that.

I'm talking about this thread btw:
http://mail-index.netbsd.org/netbsd-users/2009/03/19/msg003309.html

The gaining root issue was mentioned here:
http://mail-index.netbsd.org/netbsd-users/2009/03/18/msg003300.html
and here:
http://mail-index.netbsd.org/netbsd-users/2009/03/19/msg003313.html

 So a project that does zero about real security issues overreacted --
 probably because the code had originally come from here.  Typical.
 One can only hope that some issue comes up in openssh, and that they
 then delete openssh, too.

Yes, that's definitely something I like about OpenBSD. You can't care  
too much for security. But unfortunately, OpenBSD has some issues on  
this machine :(.

--
Jonathan

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of PGP.sig]

Re: systrace insecure [was: Re: chroot browser]

[Gregg Reynolds]

On Thu, Mar 26, 2009 at 10:12 AM, Theo de Raadt dera...@cvs.openbsd.org wrote:

 real; systrace does have the ability to grant root unless you build

Should that read does not?

 the policy specifically to do such a stupid thing (actually, I am not

-g

Re: systrace insecure [was: Re: chroot browser]

[Theo de Raadt]

 On Thu, Mar 26, 2009 at 10:12 AM, Theo de Raadt dera...@cvs.openbsd.org 
 wrote:
 
  real; systrace does have the ability to grant root unless you build
 
 Should that read does not?
 
  the policy specifically to do such a stupid thing (actually, I am not

Oh, indeed.  Sorry.  systrace cannot grant root unless set up very
strangely.

Replacement functionality if systrace is to be removed.

[Edd Barrett]

Hi there,

I was speaking to someone at OpenCON about the fundamental systrace
flaw regarding processes forking in order to bypass the checks. The
general impression I was given was that systrace is to be removed at
some point.

If this is the case, will there be a similar tool available?

I ask because I find USE_SYSTRACE (/etc/mk.conf)  essential for the
TeXLive port. It writes all over the place during the build.

Thanks

-- 
Best Regards

Edd

---
http://students.dec.bournemouth.ac.uk/ebarrett

Re: Replacement functionality if systrace is to be removed.

[Antoine Jacoutot]

On Tue, 4 Dec 2007, Edd Barrett wrote:

I ask because I find USE_SYSTRACE (/etc/mk.conf)  essential for the
TeXLive port. It writes all over the place during the build.


Better fix the port then.

--
Antoine

Re: Replacement functionality if systrace is to be removed.

[Edd Barrett]

Hi,

On 04/12/2007, Antoine Jacoutot [EMAIL PROTECTED] wrote:
 Better fix the port then.

I think you misunderstood. The port is fixed, but only because
systrace allowed me to cut the build short when the build offended.

-- 
Best Regards

Edd

---
http://students.dec.bournemouth.ac.uk/ebarrett

Re: Replacement functionality if systrace is to be removed.

[Antoine Jacoutot]

On Tue, 4 Dec 2007, Edd Barrett wrote:

On 04/12/2007, Antoine Jacoutot [EMAIL PROTECTED] wrote:

Better fix the port then.


I think you misunderstood. The port is fixed, but only because
systrace allowed me to cut the build short when the build offended.


Ah ok yes, I did misunderstand. Well this is the use for 
USE_SYSTRACE in ports indeed.


--
Antoine

Re: hardening BSD (was systrace/stsh policies)

[Joachim Schipper]

On Mon, Oct 15, 2007 at 09:30:02PM -0500, Aaron wrote:
 The types of machines I will be running (...) I run pf [on my
 workstation] and only allow pass out w/return traffic allowed, no
 services at all) will be single or dual purpose servers.. i.e. http,
 smtp, imap etc, not machines that are running X and all my fav ports
 (...) I don't allow remote logins even via ssh except for the local
 networks, I always have a firewall in front of my public servers with
 rate limits (...) and I had decided a while back i was going to forgo
 (...) the latest and greatest versions of software, due to
 simplicity/security's sake.

Sounds pretty good.

 (...) [I] _know_ I would 
 had a fit trying to get systrace policies set up, if not worse thinking i 
 had them set up right and figuring out later they weren't and i had in fact 
 lessened the security by putting all my trust in that system, at least at 
 this point in my experience.

This is a common response from OpenBSD fans when confronted with SELinux
and the like.

 From what I have comprehended both
 [systrace and securelevels] still need to have someone that has gained
 root on the box (not that my understanding might not be flawed), which
 is one of the things that OpenBSD strives to disallow.

Unless I am sorely mistaken, systrace can be broken by any user with
enough priviliges to run two processes.

I'm not really aware of any non-root problem with securelevels, but
since securelevels are almost entirely about restricting root (and not
other users - an ordinary user wouldn't notice the difference), this is

Joachim

-- 
PotD: x11/gnome/utils - GNOME utility programs

Re: hardening BSD (was systrace/stsh policies)

[Theo de Raadt]

 Unless I am sorely mistaken, systrace can be broken by any user with
 enough priviliges to run two processes.

Well, then you are sorely mistaken.  One of your processes can break
the other one.  What's the big deal.  Where's the priviledge
escalation?  There is none.

You overstate the situation.

Re: hardening BSD (was systrace/stsh policies)

[Francesco Toscan]

2007/10/14, Aaron [EMAIL PROTECTED]:
 I guess with all the hoopla about 'hardening'/trusted this and
 that/fuzzy knobs(i.e. SE Linux) i got a little overzealous looking for

As others have already pointed out these knobs might not be useful to
your setup and your needs. Think also that more complexity you add
then more likely you'll find out bugs lurking in the dark, waiting for
the right moment to bite your ass.
I have a box running FreeBSD with MAC policies configured in
production for a year now; I must be honest, the only thing I'm really
sure about is it's a royal pain to update and manage. Not a great
deal, I'm planning a switch to 4.2.

f.

Re: hardening BSD (was systrace/stsh policies)

[Eduardo Tongson]

Robert Watson's paper discusses concurrency vulnerabilities. Impact
include policy bypass and audit trail invalidation. A bypass means it
is useless. That pretty much hammered in the last nail on the coffin
for security tools based on system call interposition.

On 10/15/07, Steve Shockley [EMAIL PROTECTED] wrote:
 Joachim Schipper wrote:
  You should probably do a Google search on systrace before continuing
  further down this road. In particular, I believe the issue highlighted
  by Robert Watson has not been fixed yet (although I could be wrong, and
  would be happy to be wrong in this case).

 The white paper for the systrace vulnerability was a little bit beyond
 me; what's the impact of the issue?  Is a system running systrace *more*
 vulnerable than a normal system, or is the problem just that a
 determined user can circumvent systrace (like the bottom of systrace(1)
 suggests)?  If it's the latter, it seems like it'd still be useful for
 policy enforcement to some extent.

Re: hardening BSD (was systrace/stsh policies)

[Nick Guenther]

On 10/15/07, Eduardo Tongson [EMAIL PROTECTED] wrote:

 Robert Watson's paper discusses concurrency vulnerabilities. Impact
 include policy bypass and audit trail invalidation. A bypass means it
 is useless. That pretty much hammered in the last nail on the coffin
 for security tools based on system call interposition.

Oh really?
The abstract reads System call interposition allows the kernel security model
to be extended. However, when combined with current operating systems,
it is open to concurrency vulnerabilities leading to privilege
escalation and audit bypass.
(Paper at 
http://www.usenix.org/events/woot07/tech/full_papers/watson/watson.pdf)
and Neils Provos says
http://www.systrace.org/index.php?/archives/14-Evading-System-Sandbox-Containment.html
The initial prototype of Systrace as described in the paper avoided
this problem by using a look-aside buffer in the kernel. This imposes
a slight performance penality but I hope that this obvious solution is
going to be included in the OpenBSD and NetBSD kernel soon.

How is this the last nail at all?

-Nick

Re: hardening BSD (was systrace/stsh policies)

[Ted Unangst]

On 10/14/07, Steve Shockley [EMAIL PROTECTED] wrote:
 The white paper for the systrace vulnerability was a little bit beyond
 me; what's the impact of the issue?  Is a system running systrace *more*
 vulnerable than a normal system, or is the problem just that a
 determined user can circumvent systrace (like the bottom of systrace(1)
 suggests)?  If it's the latter, it seems like it'd still be useful for
 policy enforcement to some extent.

two processes using shared memory can cooperate to circumvent
systrace.  this means it's not very useful to contain an app after
exploitation.  also, circumvention is not silent.  if you log
failures, you'll see it happening.

systrace is still useful for keeping an eye on binary programs.  or to
make sure your apps are configured correctly (web server can't read
files outside of blah/, whatever).

Re: hardening BSD (was systrace/stsh policies)

[Janne Johansson]

Eduardo Tongson wrote:

Robert Watson's paper discusses concurrency vulnerabilities. Impact
include policy bypass and audit trail invalidation. A bypass means it
is useless. That pretty much hammered in the last nail on the coffin
for security tools based on system call interposition.



I actually dont think it is all worthless. Imagine a machine running a 
server daemon. If you systrace that particurlar daemon to not be able to 
fork()/exec*() or system(), you could be quite sure it wont start random 
apps on your machine in case someone manages to trick it somehow.


Now, if the attacker already has a local account and/or shell, he might 
run races and fool the systrace. But if this daemon was the only way for 
said attacker to gain such shell access, and it can be prevented from 
doing common stuff needed to get a local shell then you would have a 
safer system.


In this way, systrace might be usable still, even though it wont suffice 
for systrace'd shells given out to bad guys. Same as all other measures 
you might have like chroots, stack gaps, randomized mem layouts and 
library addresses, they never prevent 100% of all attacks, just many of 
them.



On 10/15/07, Steve Shockley [EMAIL PROTECTED] wrote:

Joachim Schipper wrote:

You should probably do a Google search on systrace before continuing
further down this road. In particular, I believe the issue highlighted
by Robert Watson has not been fixed yet (although I could be wrong, and
would be happy to be wrong in this case).

The white paper for the systrace vulnerability was a little bit beyond
me; what's the impact of the issue?  Is a system running systrace *more*
vulnerable than a normal system, or is the problem just that a
determined user can circumvent systrace (like the bottom of systrace(1)
suggests)?  If it's the latter, it seems like it'd still be useful for
policy enforcement to some extent.

Re: hardening BSD (was systrace/stsh policies)

[Joachim Schipper]

On Sun, Oct 14, 2007 at 03:27:20PM -0500, Aaron wrote:
 I hope i'm not out of line changing the thread but this seemed like a good 
 place to ask this question.

Not at all, and changing the thread title when changing the thread
subjet is a welcome relief from the usual misc@ practice.

I'm fairly new to OpenBSD and have set up a few machines, nothing 
 production (...). One thing I did read up on (...) was hardening
 beyond the default install. Two of the tools that most of the
 hardening articles i found, Securelevels and systrace, (the third one
 seems to be common sense), have now seemingly been rendered useless.
 (...)
I'm wondering if there are other tools/ways besides these that I just 
 haven't heard of to do similar things (hardening of the system) or if there 
 is in effect no way to do the things that, these two tools, specifically 
 systrace has historically handled(is there really a need in the first 
 place?).  I say specifically systrace because from the discussions i've 
 been reading, the whole securelevel methodology, to the people that do the 
 work on OpenBSD,  is flawed.  I'm not here to dispute or even to discuss 
 that point, as currently I can't program (nor afford to hire people that 
 can) so my likes and dislikes are moot.

I'm not aware of any current `replacement' for systrace in OpenBSD. This
is both a blessing and a curse; systrace gets its tentacles deep into
security-sensitive code, and I remember at least one instance where that
caused a bug (though not what bug).
On the other hand, systrace allows one to express a security policy
that's more fine-grained than the default UNIX permissions allow.

Like i say, i'm still relatively new to OpenBSD so I'm just looking for 
 insight, I haven't used systrace in the past, and until about a week ago 
 was working with securelevels but then found the aforementioned article.  I 
 had abandoned the securelevel method in light of the 'issue'(s)/false sense 
 of security with securelevels and from the discussion had decided to pick 
 up with systrace, until i saw this thread yesterday.
Is it more common than not, to not worry as much about hardening the 
 OS, via these methods, but rather just to make 'hopefully' wise decisions, 
 install the least amount of software as you need, physical separations(i.e. 
 logging to remote server instead of sappnd'ing your logs)(but what happens 
 when after getting root on the system producing logs, the attacker proceeds 
 to work towards your logging server?) and stay current w/at least the 
 stable branch?
I guess with all the hoopla about 'hardening'/trusted this and 
 that/fuzzy knobs(i.e. SE Linux) i got a little overzealous looking for ways 
 to tweak things (which i know can end up either making things less secure 
 (especially with false sense of security) or just plain breaking them), but 
 if there is/are acceptable, ways, I'd at least like to be aware of them and 
 the scope of their use from the people that know OpenBSD best.

It's not entirely impossible to improve on OpenBSD's default security,
although the default security is pretty good. The most obvious
improvement is disabling SSH logins using passwords, as has already been
mentioned.
It might also be a good idea to periodically audit /etc/master.passwd
for weak passwords. John the Ripper http://www.openwall.com/john/
might be useful here.

There is also something to be said for dropping all IPv6 traffic; the
IPv6 stack is not as thoroughly tested as the IPv4 stack, despite a lot
of work by the smart people of the KAME project.
In the same vein, a restrictive pf configuration might help prevent or
at least mitigate the effects of exploitation.

You could also take a good look at /etc/login.conf; it does a pretty
good job of limiting resource usage, but it's a bit more lenient than it
could be, especially for the 'daemon' group (daemons very rarely really
need the ability to allocate an unbounded amount of memory). It should
be noted that the 'daemon' group appears to be used only by ports,
though.
However, this merely prevents an attacker that has already gained access
from DoS'ing the rest of the applications on the machine.

If you have local users, you might also want to vet suid applications.
You could also move the 'root' entry in /etc/master.passwd away from the
first line; if there is a programming error whereby a suid app that can
be told to parse an arbitrary file, the password hash for root cannot be
discovered (see
http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=157
for an example of this problem; while this is not the only example I
know of, this problem is not particularly common).
This also isn't much of a problem if root has a password that is too
complex to bruteforce, which should be the case.

It could also be argued that, should you require an MTA that is
accessible from the outside world, replacing sendmail with your
favourite alternative may increase security.

Finally

Re: hardening BSD (was systrace/stsh policies)

[Aaron]

Aaron wrote:

Joachim Schipper wrote:

On Thu, Oct 11, 2007 at 08:54:42PM +0200, Xavier Mertens wrote:
 

Hi *,

I'm busy with a systrace/stsh implementation but there is a lack of 
standard

policies (IMHO). Any idea where I can find some ready-to-use policies?

I must be missing some important ones, when the user logs in, he got 
immediately

the following error:

systrace: getcwd: Permission denied



You should probably do a Google search on systrace before continuing
further down this road. In particular, I believe the issue highlighted
by Robert Watson has not been fixed yet (although I could be wrong, and
would be happy to be wrong in this case).

Otherwise, I seem to recall a repository of configurations called 'hairy
eyeball'. And the interactive policy generators (xsystrace for instance)
can be pretty useful, too.

Joachim

  
I hope i'm not out of line changing the thread but this seemed like a 
good place to ask this question.


   I'm fairly new to OpenBSD and have set up a few machines, nothing 
production, trying out configurations, rebuilding, patching etc. 
before i felt comfortable putting one in production.  One thing I did 
read up on, where i could find it, was hardening beyond the default 
install.Two of the tools that most of the hardening articles i 
found, Securelevels and systrace, (the third one seems to be common 
sense), have now seemingly been rendered useless.  I followed the huge 
thread on why can't openbsd's securelevels be saved and now this 
thread has alerted me to the fact that systrace is able to be 
circumvented.  I also noticed that Joachim commented on both so I 
figured this for a good place for this topic.
   I'm wondering if there are other tools/ways besides these that I 
just haven't heard of to do similar things(hardening of the system) or 
if there is in effect no way to do the things that, these two tools, 
specifically systrace has historically handled(is there really a need 
in the first place?).  I say specifically systrace because from the 
discussions i've been reading, the whole securelevel methodology, to 
the people that do the work on OpenBSD,  is flawed.  I'm not here to 
dispute or even to discuss that point, as currently I can't program 
(nor afford to hire people that can) so my likes and dislikes are moot.
   Like i say, i'm still relatively new to OpenBSD so I'm just looking 
for insight, I haven't used systrace in the past, and until about a 
week ago was working with securelevels but then found the 
aforementioned article.  I had abandoned the securelevel method in 
light of the 'issue'(s)/false sense of security with securelevels and 
from the discussion had decided to pick up with systrace, until i saw 
this thread yesterday.
   Is it more common than not, to not worry as much about hardening 
the OS, via these methods, but rather just to make 'hopefully' wise 
decisions, install the least amount of software as you need, physical 
separations(i.e. logging to remote server instead of sappnd'ing your 
logs)(but what happens when after getting root on the system producing 
logs, the attacker proceeds to work towards your logging server?) and 
stay current w/at least the stable branch?
   I guess with all the hoopla about 'hardening'/trusted this and 
that/fuzzy knobs(i.e. SE Linux) i got a little overzealous looking for 
ways to tweak things (which i know can end up either making things 
less secure (especially with false sense of security) or just plain 
breaking them), but if there is/are acceptable, ways, I'd at least 
like to be aware of them and the scope of their use from the people 
that know OpenBSD best.


Thanks,

Aaron

   Thanks to everyone for answering/explaining what i know is in no way 
an easy question to answer with really an infinite number of answers 
depending on the skill set of the person answering and also the level of 
the person asking.  Like I said originally I'm fairly new to Openbsd, 
and to be honest, when i read that securelevels was able to be defeated 
and to move to systrace, i was a little overwhelmed reading up on it and 
looking at the examples.  The types of machines I will be running (when 
i feel comfortable enough with openbsd)(and am concerned about 
protecting, should i be more concerned about protecting my OBSD 
workstation too?  I run pf and only allow pass out w/return traffic 
allowed, no services at all) will be single or dual purpose servers.. 
i.e. http, smtp, imap etc, not machines that are running X and all my 
fav ports like amule (not that i would ever download anything from there 
anyway, that's just not safe :-)) I don't allow remote logins even via 
ssh except for the local networks, I always have a firewall in front of 
my public servers with rate limits (overload for pf fans) and I had  
decided a while back i was going to forgo the new bells and whistles in 
the latest and greatest versions of software, due to 
simplicity/security's sake. and only  run packages

hardening BSD (was systrace/stsh policies)

[Aaron]

Joachim Schipper wrote:

On Thu, Oct 11, 2007 at 08:54:42PM +0200, Xavier Mertens wrote:
  

Hi *,

I'm busy with a systrace/stsh implementation but there is a lack of standard
policies (IMHO). Any idea where I can find some ready-to-use policies?

I must be missing some important ones, when the user logs in, he got immediately
the following error:

systrace: getcwd: Permission denied



You should probably do a Google search on systrace before continuing
further down this road. In particular, I believe the issue highlighted
by Robert Watson has not been fixed yet (although I could be wrong, and
would be happy to be wrong in this case).

Otherwise, I seem to recall a repository of configurations called 'hairy
eyeball'. And the interactive policy generators (xsystrace for instance)
can be pretty useful, too.

Joachim

  
I hope i'm not out of line changing the thread but this seemed like a 
good place to ask this question.


   I'm fairly new to OpenBSD and have set up a few machines, nothing 
production, trying out configurations, rebuilding, patching etc. before 
i felt comfortable putting one in production.  One thing I did read up 
on, where i could find it, was hardening beyond the default install. 
   Two of the tools that most of the hardening articles i found, 
Securelevels and systrace, (the third one seems to be common sense), 
have now seemingly been rendered useless.  I followed the huge thread on 
why can't openbsd's securelevels be saved and now this thread has 
alerted me to the fact that systrace is able to be circumvented.  I also 
noticed that Joachim commented on both so I figured this for a good 
place for this topic.
   I'm wondering if there are other tools/ways besides these that I 
just haven't heard of to do similar things(hardening of the system) or 
if there is in effect no way to do the things that, these two tools, 
specifically systrace has historically handled(is there really a need in 
the first place?).  I say specifically systrace because from the 
discussions i've been reading, the whole securelevel methodology, to the 
people that do the work on OpenBSD,  is flawed.  I'm not here to dispute 
or even to discuss that point, as currently I can't program (nor afford 
to hire people that can) so my likes and dislikes are moot.
   Like i say, i'm still relatively new to OpenBSD so I'm just looking 
for insight, I haven't used systrace in the past, and until about a week 
ago was working with securelevels but then found the aforementioned 
article.  I had abandoned the securelevel method in light of the 
'issue'(s)/false sense of security with securelevels and from the 
discussion had decided to pick up with systrace, until i saw this thread 
yesterday.
   Is it more common than not, to not worry as much about hardening 
the OS, via these methods, but rather just to make 'hopefully' wise 
decisions, install the least amount of software as you need, physical 
separations(i.e. logging to remote server instead of sappnd'ing your 
logs)(but what happens when after getting root on the system producing 
logs, the attacker proceeds to work towards your logging server?) and 
stay current w/at least the stable branch?
   I guess with all the hoopla about 'hardening'/trusted this and 
that/fuzzy knobs(i.e. SE Linux) i got a little overzealous looking for 
ways to tweak things (which i know can end up either making things less 
secure (especially with false sense of security) or just plain breaking 
them), but if there is/are acceptable, ways, I'd at least like to be 
aware of them and the scope of their use from the people that know 
OpenBSD best.


Thanks,

Aaron

Re: hardening BSD (was systrace/stsh policies)

[Steve Shockley]

Joachim Schipper wrote:

You should probably do a Google search on systrace before continuing
further down this road. In particular, I believe the issue highlighted
by Robert Watson has not been fixed yet (although I could be wrong, and
would be happy to be wrong in this case).


The white paper for the systrace vulnerability was a little bit beyond 
me; what's the impact of the issue?  Is a system running systrace *more* 
vulnerable than a normal system, or is the problem just that a 
determined user can circumvent systrace (like the bottom of systrace(1) 
suggests)?  If it's the latter, it seems like it'd still be useful for 
policy enforcement to some extent.

systrace/stsh policies

[Xavier Mertens]

Hi *,

I'm busy with a systrace/stsh implementation but there is a lack of standard
policies (IMHO). Any idea where I can find some ready-to-use policies?

I must be missing some important ones, when the user logs in, he got immediately
the following error:

systrace: getcwd: Permission denied

Xavier
--
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)

Re: systrace/stsh policies

[Joachim Schipper]

On Thu, Oct 11, 2007 at 08:54:42PM +0200, Xavier Mertens wrote:
 Hi *,
 
 I'm busy with a systrace/stsh implementation but there is a lack of standard
 policies (IMHO). Any idea where I can find some ready-to-use policies?
 
 I must be missing some important ones, when the user logs in, he got 
 immediately
 the following error:
 
 systrace: getcwd: Permission denied

You should probably do a Google search on systrace before continuing
further down this road. In particular, I believe the issue highlighted
by Robert Watson has not been fixed yet (although I could be wrong, and
would be happy to be wrong in this case).

Otherwise, I seem to recall a repository of configurations called 'hairy
eyeball'. And the interactive policy generators (xsystrace for instance)
can be pretty useful, too.

Joachim

-- 
TFMotD: eqn (1) - format equations for troff

Re: systrace/sysjail wrappers security

[Artur Grabowski]

Pawel Jakub Dawidek [EMAIL PROTECTED] writes:

 In my opinion there are just too many potential problems with syscall
 wrappers that I fully agree with Robert - they should not be used.

I must fully agree here. I never liked systrace and bashed sysjail really
hard because the solution is at the wrong layer where so many assumptions
can go wrong. The problem is that we haven't really created a better
framework for doing this type of things even though the users obviously
seem to think they need it, so they use whatever they can get.

One of these days ...

//art

Re: systrace/sysjail wrappers security

[Pawel Jakub Dawidek]

On Thu, Aug 09, 2007 at 11:30:47AM -0400, Niels Provos wrote:
 There is a straight forward solution for this problem.  The initial
 prototype of Systrace had a look-aside buffer in the kernel for
 copyin.  I told Robert about this, not sure if he mentioned that in
 his paper or not.   There obviously would be some associated
 performance impacts.

This is not solution to the problem Robert describes in his paper. What
you suggest can only help with one kind of race, but this is not a
complete fix. There are much more race possibilities, because how
syscall wrappers work and I consider it a design flaw, which isn't
really fixable. I was thinking a lot about this few years ago when I was
working on CerbNG, but at the end I decided to drop the project, because
some problems, as I mentioned, can't be solved and fixing others need
gross hacks, and having gross hacks especially in security software is
not the way to go.

Look-aside buffer can help only when another thread/process modify the
buffer passed to the kernel after syscall wrapper check and before
kernel use. I was playing in CerbNG with marking page as read-only to
protect against this.

Other races that can't be avoided using this technique are for example:

1. Policy elevates privileges when process is trying to open
   some file. We can create symbolic link that points at this file, call
   open on it and after syscall wrapper check we change symbolic link to
   point at /etc/master.passwd.

2. Process is allowed to open a file in its home directory. Syscall
   wrapper verifies if the process really owns that file, allows to open
   it, but we remove it and place symbolic link to another file before
   kernel gets to it.

3. Process opens some special file and when it tries to do something
   with its descriptor (eg. fchmod(2)/fchown(2)) we elevate its
   privileges. Another thread in this process after syscall wrapper
   check can close this file, open another file and use dup2(2) to reuse
   old file's descriptor - syscall wrapper allowed fchown(2) on
   descriptor X, but the kernel will have different file under X
   descriptor.

There are probably more.

In my opinion there are just too many potential problems with syscall
wrappers that I fully agree with Robert - they should not be used.

The solution, as Robert writes in his paper is to use frameworks like
Mandatory Access Control in FreeBSD where policy access to objects, that
are already locked and protected against races, eg. the kernel first
opens a file, locks it and pass a pointer to a locked vnode to the
policy. Then we can be sure no change can be made to this file that will
confuse our policy.

--
Pawel Jakub Dawidek   http://www.wheel.pl
[EMAIL PROTECTED]   http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!

[demime 1.01d removed an attachment of type application/pgp-signature]

Re: systrace/sysjail wrappers security

[Niels Provos]

There is a straight forward solution for this problem.  The initial
prototype of Systrace had a look-aside buffer in the kernel for
copyin.  I told Robert about this, not sure if he mentioned that in
his paper or not.   There obviously would be some associated
performance impacts.

Niels.

On 8/7/07, Kristaps Dzonsons [EMAIL PROTECTED] wrote:
  I am using sysjail, so I am very interested how to mitigate attacks or
  is there anything OpenBSD could change to mitigate these issues?

 Until the kernel wrapper issues have been addressed, the sysjail
 page has been updated to indicate that it SHOULD NOT be used
 (nor should any systrace(4) system, which, to the best of my
 knowledge, is only systrace(1) and Xsystrace(1)).

systrace/sysjail wrappers security

[Richard Storm]

  In the First USENIX Workshop on Offensive Technologies (WOOT07)
there was presentation
by Robert N. M. Watson:
Exploiting Concurrency Vulnerabilities in System Call Wrappers

with exploit code included how to bypass restrictions:
http://www.watson.org/~robert/2007woot/2007usenixwoot-exploitingconcurrency.pdf

It seems that syscall wrappers are vulnerable on SMP systems and
conclusion states:
Don't use system call wrappers...
 ...unless willing to rewrite OS system call handler
 Do use a security framework integrated with the kernel's copying and
synchronization

I am using sysjail, so I am very interested how to mitigate attacks or
is there anything OpenBSD could change to mitigate these issues?

Re: systrace/sysjail wrappers security

[Kristaps Dzonsons]

 I am using sysjail, so I am very interested how to mitigate attacks or
 is there anything OpenBSD could change to mitigate these issues?

Until the kernel wrapper issues have been addressed, the sysjail
page has been updated to indicate that it SHOULD NOT be used 
(nor should any systrace(4) system, which, to the best of my
knowledge, is only systrace(1) and Xsystrace(1)).

sftp systrace policy.

[RV Tec]

Hi,


I'm looking for a systrace policy that ensures that a user logged in 
sftp isn't able to change directories.


I've tired dugsong's sshd policy, but that is outdated and would require a 
systrace master to update it.


Also, I've tried to get the one[1] that appeared on undeadly.org a few 
months ago, but the website is offline. No luck googling it. ;(


I just need to make sure that a user doesn't change it's home dir.

Thanks a lot,
RV

* [1] = http://undeadly.org/cgi?action=articlesid=20040307120323

systrace: vi policy

[Jacob Yocom-Piatt]

i've read through all the docs that i can find on systrace policy generation and
enforcement and have hit a snag when trying to generate a working policy for vi
that restricts the files that can be read and written by a user. the policy is
generated by running systrace -A vi test.txt for an unprivileged user in their
home directory, performing some edits, quitting vi and editing the policy to
wildcard file paths where appropriate. running the same command with enforcement
of the auto-generated policy, systrace -a vi test.txt, yields the following:

$ systrace -a vi test.txt  
ex/vi: Error: Unable to create temporary file: Operation not permitted

when this occurs there is a corresponding series of log entries

Nov 12 08:29:36 served systrace: deny user: systest, prog: /usr/bin/vi, pid:
2684(0)[0], policy: /usr/bin/vi, filters: 60, syscall: native-fswrite(5),
filename: /tmp/bt.lP2684
Nov 12 08:29:36 served systrace: deny user: systest, prog: /usr/bin/vi, pid:
2684(0)[0], policy: /usr/bin/vi, filters: 60, syscall: native-fsread(291),
filename: /home/systest/test.txt
Nov 12 08:29:36 served systrace: deny user: systest, prog: /usr/bin/vi, pid:
2684(0)[0], policy: /usr/bin/vi, filters: 60, syscall: native-fswrite(5),
filename: /tmp/vi.HgVcdq2684

the denials of these syscalls is confusing to me since the systrace policy,
/etc/systrace/usr_bin_vi [0], contains wildcarded permit statements that should,
AFAICT, allow these syscalls. the two lines in usr_bin_vi that are meant to
allow these syscalls are marked with a  in [0] below.

since systrace obviously works for other folks, i'm missing something here. i
suspect it has to with wildcarding or environment variables. clues appreciated.

cheers,
jake

[0] - /etc/systrace/usr_bin_vi

Policy: /usr/bin/vi, Emulation: native
native-issetugid: permit
native-mprotect: permit
native-mmap: permit
native-__sysctl: permit
native-fsread: filename eq /var/run/ld.so.hints then permit
native-fstat: permit
native-close: permit
native-fsread: filename eq /usr/lib/libcurses.so.10.0 then permit
native-read: permit
native-mquery: permit
native-fsread: filename eq /usr/lib/libc.so.39.0 then permit
native-munmap: permit
native-sigprocmask: permit
native-fsread: filename eq /etc/malloc.conf then permit
native-ioctl: permit
native-fsread: filename eq $HOME/.terminfo.db then permit
native-fsread: filename eq $HOME/.terminfo then permit
native-fsread: filename eq /usr/share/misc/terminfo.db then permit
native-fcntl: permit
native-pread: permit
native-sigaction: permit
native-fsread: filename eq /usr/share/vi/catalog then permit
native-getpid: permit
native-fsread: filename eq /tmp then permit
  native-fswrite: filename eq /tmp/* then permit
native-lseek: permit
native-fsread: filename eq /etc/vi.exrc then permit
native-fsread: filename eq $HOME/.nexrc then permit
native-fsread: filename eq $HOME/.exrc then permit
  native-fsread: filename eq $HOME/* then permit
native-fsread: filename eq /var/tmp/vi.recover then permit
native-fswrite: filename eq /var/tmp/vi.recover/* then permit
native-fchmod: fd eq 3 and mode eq 700 then permit
native-flock: permit
native-write: permit
native-poll: permit
native-select: permit
native-getuid: permit
native-fsread: filename eq /etc/spwd.db then permit
native-fsread: filename eq /etc/pwd.db then permit
native-fchmod: fd eq 6 and mode eq 600 then permit
native-gettimeofday: permit
native-fsread: filename eq /usr/share/zoneinfo/US/Central then permit
native-pwrite: permit
native-fsync: permit
native-chmod: filename eq /var/tmp/vi.recover/vi.* and mode eq 600
then permit
native-fswrite: filename eq $HOME/* then permit
native-exit: permit
native-fchmod: fd eq 3 and mode eq 600 then permit
native-fsread: filename eq /usr/share/nls/C/libc.cat then permit
native-fsread: filename eq /non-existent filename:
/usr/share/nls/libc/C then permit

Re: systrace: vi policy

[Okan Demirmen]

On Sun 2006.11.12 at 08:55 -0600, Jacob Yocom-Piatt wrote:

consider sorting your policies...also, try to be more generic in other
places, for example, match /usr/lib/libc.so.*
 
 Policy: /usr/bin/vi, Emulation: native
 native-issetugid: permit
 native-mprotect: permit
 native-mmap: permit
 native-__sysctl: permit
 native-fsread: filename eq /var/run/ld.so.hints then permit
 native-fstat: permit
 native-close: permit
 native-fsread: filename eq /usr/lib/libcurses.so.10.0 then permit
 native-read: permit
 native-mquery: permit
 native-fsread: filename eq /usr/lib/libc.so.39.0 then permit
 native-munmap: permit
 native-sigprocmask: permit
 native-fsread: filename eq /etc/malloc.conf then permit
 native-ioctl: permit
 native-fsread: filename eq $HOME/.terminfo.db then permit
 native-fsread: filename eq $HOME/.terminfo then permit
 native-fsread: filename eq /usr/share/misc/terminfo.db then permit
 native-fcntl: permit
 native-pread: permit
 native-sigaction: permit
 native-fsread: filename eq /usr/share/vi/catalog then permit
 native-getpid: permit
 native-fsread: filename eq /tmp then permit
   native-fswrite: filename eq /tmp/* then permit

use match

 native-lseek: permit
 native-fsread: filename eq /etc/vi.exrc then permit
 native-fsread: filename eq $HOME/.nexrc then permit
 native-fsread: filename eq $HOME/.exrc then permit
   native-fsread: filename eq $HOME/* then permit

use match

 native-fsread: filename eq /var/tmp/vi.recover then permit
 native-fswrite: filename eq /var/tmp/vi.recover/* then permit
 native-fchmod: fd eq 3 and mode eq 700 then permit
 native-flock: permit
 native-write: permit
 native-poll: permit
 native-select: permit
 native-getuid: permit
 native-fsread: filename eq /etc/spwd.db then permit
 native-fsread: filename eq /etc/pwd.db then permit
 native-fchmod: fd eq 6 and mode eq 600 then permit
 native-gettimeofday: permit
 native-fsread: filename eq /usr/share/zoneinfo/US/Central then 
 permit
 native-pwrite: permit
 native-fsync: permit
 native-chmod: filename eq /var/tmp/vi.recover/vi.* and mode eq 600
 then permit
 native-fswrite: filename eq $HOME/* then permit
 native-exit: permit
 native-fchmod: fd eq 3 and mode eq 600 then permit
 native-fsread: filename eq /usr/share/nls/C/libc.cat then permit
 native-fsread: filename eq /non-existent filename:
 /usr/share/nls/libc/C then permit

Re: systrace: vi policy

[Jacob Yocom-Piatt]

 Original message 
Date: Sun, 12 Nov 2006 10:26:10 -0500
From: Okan Demirmen [EMAIL PROTECTED]  
Subject: Re: systrace: vi policy  
To: misc@openbsd.org

On Sun 2006.11.12 at 08:55 -0600, Jacob Yocom-Piatt wrote:

consider sorting your policies...also, try to be more generic in other
places, for example, match /usr/lib/libc.so.*
 
   native-fswrite: filename eq /tmp/* then permit

use match


okan,

that did the trick, thx for the syntax advice. is there any particular utility
you recommend for sorting the syscalls?

cheers,
jake

Re: systrace: vi policy

[Okan Demirmen]

On Sun 2006.11.12 at 12:15 -0600, Jacob Yocom-Piatt wrote:
  Original message 
 Date: Sun, 12 Nov 2006 10:26:10 -0500
 From: Okan Demirmen [EMAIL PROTECTED]  
 Subject: Re: systrace: vi policy  
 To: misc@openbsd.org
 
 On Sun 2006.11.12 at 08:55 -0600, Jacob Yocom-Piatt wrote:
 
 consider sorting your policies...also, try to be more generic in other
 places, for example, match /usr/lib/libc.so.*
  
native-fswrite: filename eq /tmp/* then permit
 
 use match
 
 
 okan,
 
 that did the trick, thx for the syntax advice. is there any particular utility
 you recommend for sorting the syscalls?

no problem.  not to state the obvious, but use sort(1).  call it within
your favorite editor ;)

cheers.

Re: systrace: vi policy

[Ben Calvert]

On Sun, 12 Nov 2006 12:15:39 -0600 (CST)
Jacob Yocom-Piatt [EMAIL PROTECTED] wrote:

  Original message 
 Date: Sun, 12 Nov 2006 10:26:10 -0500
 From: Okan Demirmen [EMAIL PROTECTED]  
 Subject: Re: systrace: vi policy  
 To: misc@openbsd.org
 
 On Sun 2006.11.12 at 08:55 -0600, Jacob Yocom-Piatt wrote:
 
 consider sorting your policies...also, try to be more generic in
 other places, for example, match /usr/lib/libc.so.*
  
native-fswrite: filename eq /tmp/* then permit
 
 use match
 
 
 okan,
 
 that did the trick, thx for the syntax advice. is there any
 particular utility you recommend for sorting the syscalls?

have you tried  sort(1) ?

 
 cheers,
 jake
 

Ben

-
I'm also not very analytical.  You know I don't spend a lot of time
thinking about myself, about why I do things.

George W. Bush
June 4, 2003
Aboard Air Force One

systrace / stsh: logging, etc.

[Jacob Yocom-Piatt]

having seen and experimented with both jose's (
http://www.monkey.org/~jose/software/stsh/ ) and dug's (
http://mirror.sg.depaul.edu/pub/security/stsh/dugsong-stsh.txt ) stsh tarballs,
i found that jose's works nicely with minimal effort and dug's throws up an
invalid shell error. does anyone have a strong suggestion as to which stsh
source to use?

when a syscall is denied, i get a lot of repeated messages in /var/log/messages
(haven't changed where systrace logs to yet) like so

Nov  4 19:21:00 rp systrace: deny user: stest, prog: /usr/bin/vi, pid:
14493(2)[19027], policy: /usr/bin/vi, filters: 0, syscall: native-write(4), 
args: 12
Nov  4 19:21:00 rp systrace: deny user: stest, prog: /usr/bin/vi, pid:
14493(2)[19027], policy: /usr/bin/vi, filters: 0, syscall: native-write(4), 
args: 12
Nov  4 19:21:00 rp systrace: deny user: stest, prog: /usr/bin/vi, pid:
14493(2)[19027], policy: /usr/bin/vi, filters: 0, syscall: native-write(4), 
args: 12
Nov  4 19:21:00 rp systrace: deny user: stest, prog: /usr/bin/vi, pid:
14493(2)[19027], policy: /usr/bin/vi, filters: 0, syscall: native-write(4), 
args: 12
Nov  4 19:21:00 rp systrace: deny user: stest, prog: /usr/bin/vi, pid:
14493(2)[19027], policy: /usr/bin/vi, filters: 0, syscall: native-write(4), 
args: 12
Nov  4 19:21:00 rp systrace: deny user: stest, prog: /usr/bin/vi, pid:
14493(2)[19027], policy: /usr/bin/vi, filters: 0, syscall: native-write(4), 
args: 12
Nov  4 19:21:00 rp systrace: deny user: stest, prog: /usr/bin/vi, pid:
14493(2)[19027], policy: /usr/bin/vi, filters: 0, syscall: native-write(4), 
args: 12

how can i condense these into a single entry followed by a last entry repeated
X times entry?

cheers,
jake

Re: OpenBSD / NetBSD systrace kernel integer overflow

[Dries Schellekens]

Nicolas Martzel wrote:

http://scary.beasts.org/security/CESA-2006-003.html

Feedback about that ?
Corrected or always active ?


http://www.openbsd.org/errata.html#systrace

Re: OpenBSD / NetBSD systrace kernel integer overflow

[Otto Moerbeek]

On Tue, 24 Oct 2006, Nicolas Martzel wrote:

 http://scary.beasts.org/security/CESA-2006-003.html
 
 Feedback about that ?
 Corrected or always active ?
 
 Thanks, and hope that could help.

Eh, why don't you look at http://www.openbsd.org/errata.html first?
It's already fixed for more than two weeks.

-Otto

Re: OpenBSD / NetBSD systrace kernel integer overflow

[ropers]

On 24/10/06, Nicolas Martzel [EMAIL PROTECTED] wrote:

http://scary.beasts.org/security/CESA-2006-003.html

Feedback about that ?
Corrected or always active ?

Thanks, and hope that could help.


Ask question?
Complete sentence?
You talking to me?
Thanks, and hope that could help.

Re: OpenBSD / NetBSD systrace kernel integer overflow

[Matthias Kilian]

On Tue, Oct 24, 2006 at 03:09:12PM +0200, Nicolas Martzel wrote:
 http://scary.beasts.org/security/CESA-2006-003.html

http://www.openbsd.org/errata.html#systrace

Re: OpenBSD / NetBSD systrace kernel integer overflow

[Nicolas Martzel]

I thank you all, but M ropers whom the reaction is displaced.
At the begining of the project i manage i had an argue with the security expert 
of my company.
He wanted MacOSX servers, and i wanted OpenBSD. I finally win and i am very 
happy of my choice.
He just gives me the link i have sent you, and now tells me Wow they are 
quicker than apple. Lol.

Again thanks, bye.


 Message du 24/10/06 15:25
 De : Matthias Kilian [EMAIL PROTECTED]
 A : Nicolas Martzel [EMAIL PROTECTED]
 Copie C  : misc@openbsd.org
 Objet : Re: OpenBSD / NetBSD systrace kernel integer overflow
 
 On Tue, Oct 24, 2006 at 03:09:12PM +0200, Nicolas Martzel wrote:
  http://scary.beasts.org/security/CESA-2006-003.html
 
 http://www.openbsd.org/errata.html#systrace
 ---
 Orange vous informe que cet  e-mail a ete controle par l'anti-virus mail. 
 Aucun virus connu a ce jour par nos services n'a ete detecte.

Re: OpenBSD / NetBSD systrace kernel integer overflow

[ropers]

On 24/10/06, Nicolas Martzel [EMAIL PROTECTED] wrote:

I thank you all, but M ropers whom the reaction is displaced.


:D

Thank you. :-) That's almost the only time I've laughed today.
(Hey, no hard feelings, right?)
--ropers

Re: fping systrace

[Julien TOUCHE]

Steffen Schuetz wrote on 02/09/2006 22:47:
 native-getuid: permit as root doesn't work in a systrace policy
 
 You should try true then permit as root

yes, that's it.
have forgotten the true :)

thanks
Regards

Julien

Re: fping systrace

[Julien TOUCHE]

Ted Unangst wrote on 01/09/2006 23:54:
 isn't it limited to a deny (returning an errorcode) ? so how ?

 native-getuid: permit

 native-getuid: permit[0] = error
 native-getuid: permit as root = error
 
 yeah, actually i think you want as root, but for geteuid or whatever
 the right syscall is.
 

i don't get it ???

native-getuid: permit as root doesn't work in a systrace policy

$ sudo /bin/systrace -a -c 556:556 /usr/local/sbin/fping localhost
syntax error
/etc/systrace/usr_local_sbin_fping:24: syntax error.
Segmentation fault

and same for adding a return code to permit.

nobody with systrace privilege evelation and fping ?

thanks
Regards

Julien

Re: fping systrace

[Steffen Schuetz]

On Saturday 02 September 2006 12:14, Julien TOUCHE wrote:
[cut]

 i don't get it ???

 native-getuid: permit as root doesn't work in a systrace policy

You should try true then permit as root

 $ sudo /bin/systrace -a -c 556:556 /usr/local/sbin/fping localhost
 syntax error
 /etc/systrace/usr_local_sbin_fping:24: syntax error.
 Segmentation fault

 and same for adding a return code to permit.

 nobody with systrace privilege evelation and fping ?

The following policy works for me:

Policy: /usr/local/sbin/fping, Emulation: native
native-geteuid: true then permit as root
native-getuid: true then permit as root
native-socket: sockdom eq AF_INET and socktype eq SOCK_RAW then 
permit as root
native-issetugid: permit
native-mprotect: prot eq PROT_READ then permit
native-mmap: prot eq PROT_READ|PROT_WRITE then permit
native-fsread: filename eq /var/run/ld.so.hints then permit
native-fstat: permit
native-mmap: prot eq PROT_READ then permit
native-close: permit
native-fsread: filename eq /usr/lib/libc.so.39.2 then permit
native-read: permit
native-mmap: prot eq PROT_NONE then permit
native-mmap: prot eq PROT_READ|PROT_EXEC then permit
native-mprotect: prot eq PROT_READ|PROT_WRITE then permit
native-mprotect: prot eq PROT_READ|PROT_WRITE|PROT_EXEC then permit
native-mprotect: prot eq PROT_READ|PROT_EXEC then permit
native-munmap: permit
native-sigprocmask: permit
native-__sysctl: permit
native-fsread: filename eq /etc/protocols then permit
native-fsread: filename eq /etc/malloc.conf then permit
native-seteuid: uid eq 0 and uname eq root then permit
native-setuid: uid eq 0 and uname eq root then permit
native-getpid: permit
native-sigaction: permit
native-gettimeofday: permit
native-sendto: sockaddr match inet-*:0 then permit
native-select: permit
native-recvfrom: permit
native-ioctl: permit
native-write: permit
native-exit: permit

fping systrace

[Julien TOUCHE]

i want to use fping with with nrpe/nagios. as security doc of OpenBSD
state, i want to use systrace privilege elevation but ...

$ sudo /bin/systrace -a -c 556:556 /usr/local/sbin/fping localhost
This program can only be run by root, or it must be setuid root.
$ sudo /bin/systrace -a /usr/local/sbin/fping -qc 5 localhost
localhost : xmt/rcv/%loss = 5/5/0%, min/avg/max = 0.71/1.07/1.92

seems fping runs a root check which cannot be overcome by a switch (at
least in man)
even if the policy of fping is with as root for everything it can't
run ...
anything beyond editing the code ?

thanks
Regards

Julien

Re: fping systrace

[Julien TOUCHE]

Ted Unangst wrote on 01/09/2006 21:21:
 seems fping runs a root check which cannot be overcome by a switch (at
 least in man)
 even if the policy of fping is with as root for everything it can't
 run ...
 anything beyond editing the code ?
 
 tried setting the policy to have getuid return an error of 0?
 
 

isn't it limited to a deny (returning an errorcode) ? so how ?

native-getuid: permit

native-getuid: permit[0] = error
native-getuid: permit as root = error


Regards

Julien

Re: fping systrace

[Ted Unangst]

On 9/1/06, Julien TOUCHE [EMAIL PROTECTED] wrote:

 tried setting the policy to have getuid return an error of 0?



isn't it limited to a deny (returning an errorcode) ? so how ?

native-getuid: permit

native-getuid: permit[0] = error
native-getuid: permit as root = error


yeah, actually i think you want as root, but for geteuid or whatever
the right syscall is.

systrace parse error

[Antonios Anastasiadis]

hello.
I am running a chrooted apache with php and symon/syweb, all working
fine by this point.
Trying to run in in a systrace-constrained environment I stumble upon
this error :

# systrace -A /usr/sbin/httpd
# syntax error
Parse error.
systrace: Filter generation error: filename eq /bin/sh and argv eq
sh -c /bin/rrdtool graph
/symon/cache/1157027400_f58510cabcbe4d2a641ba7a6f07a '-v bits/s'
'-t if(ath0) of hub' '-w 300' '-h 225' '-s -86400' '-e -1'
'DEF:in=/symon/rrds/hub/if_ath0.rrd:ibytes:AVERAGE'
'DEF:out=/symon/rrds/hub/if_ath0.rrd:obytes:AVERAGE'
'DEF:inp=/symon/rrds/hub/if_ath0.rrd:ipackets:AVERAGE'
'DEF:outp=/symon/rrds/hub/if_ath0.rrd:opackets:AVERAGE'
'DEF:coll=/symon/rrds/hub/if_ath0.rrd:collisions:AVERAGE'
'CDEF:nodata=in,UN,0,*' 'CDEF:inb=in,8,*' 'CDEF:outb=out,8,*'
'CDEF:noutb=outb,-1,*' 'CDEF:pmax=inb,100,/,102,*'
'CDEF:nmax=noutb,100,/,102,*' 'CDEF:totp=inp,outp,+'
'CDEF:per=coll,totp,/,100,*' 'CDEF:p0=per,0,EQ,INF,0,IF'
'CDEF:p10=per,10,LE,INF,0,IF,per,1,GT,INF,0,IF,MIN'
'CDEF:p20=per,20,LE,INF,0,IF,per,10,GT,INF,0,IF,MIN'
'CDEF:p30=per,30,LE,INF,0,IF,per,20,GT,INF,0,IF,MIN'
'CDEF:p40=per,40,LE,INF,0,IF,per,30,GT,INF,0,IF,MIN'
'CDEF:p50=per,50,LE,INF,0,IF,per,40,GT,INF,0,IF,MIN'
'CDEF:p60=per,60,LE,INF,0,IF,per,50,GT,INF,0,IF,MIN'
'CDEF:p70=per,70,LE,INF,0,IF,per,60,GT,INF,0,IF,MIN'
'CDEF:p80=per,80,LE,INF,0,IF,per,70,GT,INF,0,IF,MIN'
'CDEF:p90=per,80,LE,INF,0,IF,per,80,GT,INF,0,IF,MIN'
'CDEF:p100=per,100,LE,INF,0,IF,per,90,GT,INF,0,IF,MIN'
'CDEF:n0=p0,-1,*' 'CDEF:n10=p10,-1,*' 'CDEF:n20=p20,-1,*'
'CDEF:n30=p30,-1,*' 'CDEF:n40=p40,-1,*' 'CDEF:n50=p50,-1,*'
'CDEF:n60=p60,-1,*' 'CDEF:n70=p70,-1,*' 'CDEF:n80=p80,-1,*'
'CDEF:n90=p90,-1,*' 'CDEF:n100=p100,-1,*' 'LINE1:pmax' 'LINE1:nmax'
'COMMENT:   min  avg  max  last\\n'
'LINE1:nodata#FF' 'AREA:inb#00FF00:in ' 'GPRINT:inb:MIN: %6.2lf
%sbps' 'GPRINT:inb:AVERAGE:%6.2lf %sbps' 'GPRINT:inb:MAX:%6.2lf %sbps'
'GPRINT:inb:LAST:%6.2lf %sbps\\n' 'STACK:p0#FAFFFA' 'STACK:p10#E6'
'STACK:p20#FFD900' 'STACK:p30#FD6724' 'STACK:p40#E61800'
'STACK:p50#AB2934' 'STACK:p60#B2888B' 'STACK:p70#CC91BA'
'STACK:p80#6A2990' 'STACK:p90#0571B0' 'STACK:p100#00'
'AREA:noutb#00:out ' 'GPRINT:outb:MIN:%6.2lf %sbps'
'GPRINT:outb:AVERAGE:%6.2lf %sbps' 'GPRINT:outb:MAX:%6.2lf %sbps'
'GPRINT:outb:

which happens when I try to browse through the symon statistics page.
systrace/httpd terminates, so I cannot have a fully working auto-made
systrace policy.
Is that a bug?

dmesg following

OpenBSD 4.0-beta (GENERIC) #1039: Wed Aug  2 12:10:09 MDT 2006
   [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium III (GenuineIntel 686-class) 799 MHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real mem  = 267993088 (261712K)
avail mem = 236920832 (231368K)
using 3297 buffers containing 13504512 bytes (13188K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(e0) BIOS, date 03/13/00, BIOS32 rev. 0 @
0xf0680, SMBIOS rev. 2.3 @ 0xf1d30 (42 entries)
bios0: ASUSTeK Computer INC. P3V133
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
apm0: flags 30102 dobusy 0 doidle 1
pcibios0 at bios0: rev 2.1 @ 0xf/0xd02
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf0c80/128 (6 entries)
pcibios0: PCI Interrupt Router at 000:04:0 (VIA VT82C586 ISA rev 0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0x8000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 VIA VT82C691 PCI rev 0x44
ppb0 at pci0 dev 1 function 0 VIA VT82C598 AGP rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 S3 ViRGE GX2 rev 0x04
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 4 function 0 VIA VT82C596A ISA rev 0x23
pciide0 at pci0 dev 4 function 1 VIA VT82C571 IDE rev 0x10: ATA66,
channel 0 configured to compatibility, channel 1 configured to
compatibility
wd0 at pciide0 channel 0 drive 0: ST3200826A
wd0: 16-sector PIO, LBA48, 190782MB, 390721968 sectors
wd1 at pciide0 channel 0 drive 1: ST3200826A
wd1: 16-sector PIO, LBA48, 190782MB, 390721968 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 4
wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 4
wd2 at pciide0 channel 1 drive 0: Maxtor 6Y200P0
wd2: 16-sector PIO, LBA48, 194481MB, 398297088 sectors
wd2(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 4
VIA VT82C596 Power rev 0x30 at pci0 dev 4 function 3 not configured
vr0 at pci0 dev 9 function 0 VIA VT6105 RhineIII rev 0x8b: irq 10,
address 00:0d:61:02:15:33
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 9: OUI
0x004063, model 0x0034
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pmsi0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pmsi0 mux 0
pcppi0 at isa0

Systrace Logging Redirection

[Seth Hanford]

Hey all,

I've been experimenting with systrace and several programs on OpenBSD
3.9-stable. I'm pleased with what the tool lets me do, and with its
output, but can't find a way to get it to log to a different file for
each systrace'd service.

For example, I prepend the following to my otherwise-default syslog.conf

!!systrace
*.* /var/log/systrace/systrace
!*

Then I run thttpd and named under systrace. Both will log to
/var/log/systrace/systrace, but is there a way to get them to each log
to their own file, such as /var/log/systrace/thttpd and
/var/log/systrace/named?

If I understand correctly, even though thttpd and named might log under
different facilities, there's no option in systrace to specify a
facility name. Without this I think my answer is no, but was hoping some
ingenious hacker might have a solution.

Thanks,
Seth

Re: Systrace Logging Redirection

[Jiri Belka]

Cituji Seth Hanford [EMAIL PROTECTED]:


Hey all,

I've been experimenting with systrace and several programs on OpenBSD
3.9-stable. I'm pleased with what the tool lets me do, and with its
output, but can't find a way to get it to log to a different file for
each systrace'd service.

For example, I prepend the following to my otherwise-default syslog.conf

!!systrace
*.* /var/log/systrace/systrace
!*

Then I run thttpd and named under systrace. Both will log to
/var/log/systrace/systrace, but is there a way to get them to each log
to their own file, such as /var/log/systrace/thttpd and
/var/log/systrace/named?

If I understand correctly, even though thttpd and named might log under
different facilities, there's no option in systrace to specify a
facility name. Without this I think my answer is no, but was hoping some
ingenious hacker might have a solution.


hi, what about to sort loggin with syslog-ng, it has built-in regex...

--
jirib

Re: Systrace Logging Redirection

[Joachim Schipper]

On Tue, Aug 08, 2006 at 11:00:14AM -0400, Seth Hanford wrote:
 Hey all,
 
 I've been experimenting with systrace and several programs on OpenBSD
 3.9-stable. I'm pleased with what the tool lets me do, and with its
 output, but can't find a way to get it to log to a different file for
 each systrace'd service.
 
 For example, I prepend the following to my otherwise-default syslog.conf
 
 !!systrace
 *.*   /var/log/systrace/systrace
 !*
 
 Then I run thttpd and named under systrace. Both will log to
 /var/log/systrace/systrace, but is there a way to get them to each log
 to their own file, such as /var/log/systrace/thttpd and
 /var/log/systrace/named?
 
 If I understand correctly, even though thttpd and named might log under
 different facilities, there's no option in systrace to specify a
 facility name. Without this I think my answer is no, but was hoping some
 ingenious hacker might have a solution.

What about systrace -e? It logs to stdout. Write a little program in
your favourite language[1] to send it to syslog with the proper
facility/priority.

Joachim

[1] I know how to do this in Perl and C, and inefficiently in the Bourne
shell. It should be possible in any language with decent UNIX support.