OpenBSD desktop
Hello. I have heard on IRC that I am running a vulnerable version of Firefox, despite running 'pkg_add -a -u', on my OpenBSD 5.2 system. The advice I got was to run snapshots, because OpenBSD does not have the human resources to maintain packages. I understand this is a problem, but I want to understand the best way of dealing with this problem. Am I expected to run 'pkg_add -a -u -n' daily, and then decide when to update to a -current snapshot and package tree? I am not being sarcastic... I have every intention of continuing to run OpenBSD, and I would like to know the best way of doing it. Thank you.
Re: Isolating Firefox in a nested X server, and running as a different user
On Sun, Dec 16, 2012 at 02:21:59PM -0800, Robert Connolly wrote: > I would like to hear comments about using pf to filter user/group, > to make sure Firefox uses a proxy. The idea behind this is to stop > Firefox from leaking my IP. Is this the most efficient way to do > this? I block an user using torified firefox with PF but remember there are some issues - ping is done under root account and iirc dns resolving as well. I use dnscrypt-proxy, I used to have pdnsd running which was using dnscrypt-proxy and dns via tor (if tor was running). Too complicated :) jirib
Re: Isolating Firefox in a nested X server, and running as a different user
Ok. I took the suggestions, and now have: Xephyr -screen 1358x693 :1 & ssh -Xf firefox@localhost 'twm -display :1 & firefox -no-remote --display :1' I found the xsel(1) scripts to do copying and pasting from different displays, and it works with some getting used to. I intend to make some title bar buttons to make this easier. I still don't know whether I should be running Xephyr as my user, or as the firefox user. Also, would the sshd_config ForceCommand option be a good idea? ForceCommand twm -display :1 & firefox -no-remote --display :1 It's working well. After using xset to match my mouse settings, I still notice a touch of mouse lag, but it's completely usable. I would like to hear comments about using pf to filter user/group, to make sure Firefox uses a proxy. The idea behind this is to stop Firefox from leaking my IP. Is this the most efficient way to do this? Thanks
Re: Wireless WPA and crypto hardware
On Sun, Dec 16, 2012 at 01:52:10PM +0100, Martin Kjær Jørgensen wrote: > Sounds like OpenBSD is not quite ready for being a production Access Point. Well, that depends on your needs. But yes, alternatives like OpenWRT are tuned better for use as a speedy access point and run on smaller devices than OpenBSD does. You might want to consider putting that on your 133MHz PC instead. However, it uses busybox, iptables, and the documentation is a joke. Which so far has been putting me off much more than low transmit speed. If I want speed I just plug in a cable. But your priorities may vary.
Re: for students or your children
HI ..hehe ya i know but its for kids :D and its not about fame and glory... On Fri, Dec 14, 2012 at 5:52 AM, Tobias Ulmer wrote: > On Wed, Dec 12, 2012 at 11:03:50AM +0530, Jay Patel wrote: > > Hi all .. > > > > is OpenBSD taking part in google code-in : > > The answer is No, as far as I'm aware. Did you have a specific project in > mind? You can get fame and glory without participating in Google-sponsored > events :) > > > > > http://www.google-melange.com/gci/homepage/google/gci2012 > > > > Thanks, > > Jay.
Re: KSH command logged to syslog
On Sun, Dec 16, 2012 at 8:07 AM, Alexander Hall wrote: > > I still want to know the reason for all this. If it's for security, it sure > feels ass-backwards and questionable at best. > it's useful for honeypot scenarios, with all proposed solutions so far being influenced by either lazyness or desire to maintain a modicum of portability with other unices. it's not useful for accounting on regular accounts the best balance between effort and results i believe is to extend the ktrace hooks to switch on curproc uid and put a cap on the logfile. what apis linux honeypot loggers use? do they sufficiently resemble ktrace? it's the only facility i see in openbsd besides systrace that fits the bill of already logging all sorts of io (not just pty)
Re: Wireless WPA and crypto hardware
On Sat, Dec 15, 2012 at 06:24:38PM +0100, Stefan Sperling wrote: > On Sat, Dec 15, 2012 at 12:00:07PM -0500, Nick Holland wrote: > > On 12/15/12 11:45, Martin Kjær Jørgensen wrote: > > > Do you think an AMD Elan 133 Mhz is "modern" enough for at 54/mbit > > > wireless WPA2 throughput? > > > > Are you kidding me? > > That's about as non-modern as OpenBSD/i386 supports. Seriously. > > That's a 4x clock multiplied 486. > > The only things less modern and supported are 3x, 2x, and 1x 486 chips. > > > > The machines I have seen those chips in have difficulty pumping that > > much data, ignoring encryption (though in large part, I suspect, due to > > the crappy NIC chips). > > > > Nick. > > Not to mention that OpenBSD-based access points rarely sustain 54Mbit/s > throughput in general. Rate adaptation in the net80211 stack is rather basic. > Most of the time slower speeds are selected even if in close range to the AP. > There's a high amount of interference where I live and wireless speed > usually settles at 1 or 2Mbit/s even right next to the AP. > > sephe at Dragonfly has made some interesting changes to rate adaptation > in his patches to their version of ral(4) and the Dragonfly network stack. > I took a look at them once but they're mostly over my head so I gave up on > porting them. But such improvements are unlikely to help a 133Mhz PC anyway :) > Sounds like OpenBSD is not quite ready for being a production Access Point.
Re: KSH command logged to syslog
Andres Perera wrote:
>On Sun, Dec 16, 2012 at 7:10 AM, Paul de Weerd
>wrote:
>> On Sun, Dec 16, 2012 at 06:38:08AM -0430, Andres Perera wrote:
>> | On Sun, Dec 16, 2012 at 5:47 AM, Paul de Weerd
>wrote:
>> | > On Sun, Dec 16, 2012 at 11:02:31AM +0100, David Coppa wrote:
>> | > | > .profile can be interrupted with ctrl+c.
>> | > |
>> | > | >>> Because it is under controle or the user and he/she can
>disable
>> | > | >>> such funcionality.
>> | > |
>> | > | the safer way imho is patching ksh
>> | >
>> | > After that, expect all your users to suddenly switch to one of
>the
>> | > other shells available on your system...
>> |
>> | because once you patch ksh, you can't ever again edit /etc/shells
>>
>> switching shells:
>>
>> Step 1: login
>> Step 2: exec (zsh|csh|perl|tcsh|bash|...)
>> Step 3: ...
>> Step 4: profit
>>
>> Sure, you can edit /etc/shells and prevent users from changing their
>> login shells with chsh, but what does that buy you if they can still
>> switch shells ?
>
>no, you are patching ksh for a reason. you add logging capabilities
>and remove the ability to exec. is it a featureful shell, not really
>
>then again, is the resulting patched ksh significantly different than
>some free shell hosts provide? nope, they both tend to be as useless.
>if i recall correctly, sdf had such a stunted shell
>
>>
>> And besides .. the users that want to run another shell in the first
>> place are screwed ? You'd have to patch 'em all .. good luck with
>> maintaining that.
>
>the alternative login shell below is even more restrictive; only
>/bin/sh. ksh in posix mode isn't fun at all. this is the price you pay
>for security in 2013
>
>>
>>
>> Then, you could log all stdin/stdout to some file (even more data!
>> fun!). If you really want to circumvent this logging, you could
>> create a covert channel that will show data on the client side but
>has
>> no visible input/output in the server side.
>
>well, it's logging terminal input. does what it says in the can
>
>the can doesn't say "logs arbitrary socket io"
>
>>
>>
>> I'm still curious why any of this is a good idea.
>>
>> | > Or a nice syslog DoS, where people run while :; do echo ${RANDOM}
>>
>> | > /dev/null; done (or a less intentional version of the same) to
>flood
>> | > your logs with crap.
>> |
>> | and fsize becomes immutable as well apparently (syslog be
>forgotten)
>>
>> Not sure I understand your point here. What about fsize ? You want
>> to limit the size of the logfile ? So that all you have to do is
>fill
>> it up to the max size and then you can do whatever you want without
>> having your actions logged ?
>
>now that i think about it, it wouldn't work with O_APPEND ~O_CREAT on
>the logfile below
>
>i'm not sure "whatever you want without having your actions logged" is
>accurate in the original case, since ksh aborts by default on SIGXFSZ
>and modifications to builtins can make it uncatchable
>
>in any case, presumably the quota system is up to spec and the writing
>is done entirely by the user
I still want to know the reason for all this. If it's for security, it sure
feels ass-backwards and questionable at best.
Re: KSH command logged to syslog
On Sun, Dec 16, 2012 at 7:10 AM, Paul de Weerd wrote:
> On Sun, Dec 16, 2012 at 06:38:08AM -0430, Andres Perera wrote:
> | On Sun, Dec 16, 2012 at 5:47 AM, Paul de Weerd wrote:
> | > On Sun, Dec 16, 2012 at 11:02:31AM +0100, David Coppa wrote:
> | > | > .profile can be interrupted with ctrl+c.
> | > |
> | > | >>> Because it is under controle or the user and he/she can disable
> | > | >>> such funcionality.
> | > |
> | > | the safer way imho is patching ksh
> | >
> | > After that, expect all your users to suddenly switch to one of the
> | > other shells available on your system...
> |
> | because once you patch ksh, you can't ever again edit /etc/shells
>
> switching shells:
>
> Step 1: login
> Step 2: exec (zsh|csh|perl|tcsh|bash|...)
> Step 3: ...
> Step 4: profit
>
> Sure, you can edit /etc/shells and prevent users from changing their
> login shells with chsh, but what does that buy you if they can still
> switch shells ?
no, you are patching ksh for a reason. you add logging capabilities
and remove the ability to exec. is it a featureful shell, not really
then again, is the resulting patched ksh significantly different than
some free shell hosts provide? nope, they both tend to be as useless.
if i recall correctly, sdf had such a stunted shell
>
> And besides .. the users that want to run another shell in the first
> place are screwed ? You'd have to patch 'em all .. good luck with
> maintaining that.
the alternative login shell below is even more restrictive; only
/bin/sh. ksh in posix mode isn't fun at all. this is the price you pay
for security in 2013
>
>
> Then, you could log all stdin/stdout to some file (even more data!
> fun!). If you really want to circumvent this logging, you could
> create a covert channel that will show data on the client side but has
> no visible input/output in the server side.
well, it's logging terminal input. does what it says in the can
the can doesn't say "logs arbitrary socket io"
>
>
> I'm still curious why any of this is a good idea.
>
> | > Or a nice syslog DoS, where people run while :; do echo ${RANDOM} >
> | > /dev/null; done (or a less intentional version of the same) to flood
> | > your logs with crap.
> |
> | and fsize becomes immutable as well apparently (syslog be forgotten)
>
> Not sure I understand your point here. What about fsize ? You want
> to limit the size of the logfile ? So that all you have to do is fill
> it up to the max size and then you can do whatever you want without
> having your actions logged ?
now that i think about it, it wouldn't work with O_APPEND ~O_CREAT on
the logfile below
i'm not sure "whatever you want without having your actions logged" is
accurate in the original case, since ksh aborts by default on SIGXFSZ
and modifications to builtins can make it uncatchable
in any case, presumably the quota system is up to spec and the writing
is done entirely by the user
Re: KSH command logged to syslog
On Sun, Dec 16, 2012 at 06:38:08AM -0430, Andres Perera wrote:
| On Sun, Dec 16, 2012 at 5:47 AM, Paul de Weerd wrote:
| > On Sun, Dec 16, 2012 at 11:02:31AM +0100, David Coppa wrote:
| > | > .profile can be interrupted with ctrl+c.
| > |
| > | >>> Because it is under controle or the user and he/she can disable
| > | >>> such funcionality.
| > |
| > | the safer way imho is patching ksh
| >
| > After that, expect all your users to suddenly switch to one of the
| > other shells available on your system...
|
| because once you patch ksh, you can't ever again edit /etc/shells
switching shells:
Step 1: login
Step 2: exec (zsh|csh|perl|tcsh|bash|...)
Step 3: ...
Step 4: profit
Sure, you can edit /etc/shells and prevent users from changing their
login shells with chsh, but what does that buy you if they can still
switch shells ?
And besides .. the users that want to run another shell in the first
place are screwed ? You'd have to patch 'em all .. good luck with
maintaining that.
Then, you could log all stdin/stdout to some file (even more data!
fun!). If you really want to circumvent this logging, you could
create a covert channel that will show data on the client side but has
no visible input/output in the server side.
I'm still curious why any of this is a good idea.
| > Or a nice syslog DoS, where people run while :; do echo ${RANDOM} >
| > /dev/null; done (or a less intentional version of the same) to flood
| > your logs with crap.
|
| and fsize becomes immutable as well apparently (syslog be forgotten)
Not sure I understand your point here. What about fsize ? You want
to limit the size of the logfile ? So that all you have to do is fill
it up to the max size and then you can do whatever you want without
having your actions logged ?
| here is something that doesn't require patching
|
| create log files and change to system append-only with chflags. dir
| should be, e.g., chown root:wheel, chmod go=rx
|
| #include
| #include
| #include
| #define sp "/usr/bin/script"
| #define sf "/var/db/ghetto_act/%ju"
|
| main()
| {
| char *so;
| if (asprintf(&so, sf, getuid()) == -1) return 1/0;
| execl(sp, sp, "-a", so, NULL);
| return 1/0;
| }
|
| >
| > Why is this a good idea, exactly ?
| >
| > Paul 'WEiRD' de Weerd
| >
| > --
| >>[<++>-]<+++.>+++[<-->-]<.>+++[<+
| > +++>-]<.>++[<>-]<+.--.[-]
|
| o look, a brainfuck program. this is so quirky and tech oriented i
| feel identified with you
Great, glad you like it.
Paul 'WEiRD' de Weerd
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
Re: KSH command logged to syslog
btw, this program should be the only entry in /etc/shells so only root
is allowed privacy
On Sun, Dec 16, 2012 at 6:38 AM, Andres Perera wrote:
>
> #include
> #include
> #include
> #define sp "/usr/bin/script"
> #define sf "/var/db/ghetto_act/%ju"
>
> main()
> {
> char *so;
> if (asprintf(&so, sf, getuid()) == -1) return 1/0;
> execl(sp, sp, "-a", so, NULL);
> return 1/0;
> }
Re: KSH command logged to syslog
On Sun, Dec 16, 2012 at 5:47 AM, Paul de Weerd wrote:
> On Sun, Dec 16, 2012 at 11:02:31AM +0100, David Coppa wrote:
> | > .profile can be interrupted with ctrl+c.
> |
> | >>> Because it is under controle or the user and he/she can disable
> | >>> such funcionality.
> |
> | the safer way imho is patching ksh
>
> After that, expect all your users to suddenly switch to one of the
> other shells available on your system...
because once you patch ksh, you can't ever again edit /etc/shells
>
> Or a nice syslog DoS, where people run while :; do echo ${RANDOM} >
> /dev/null; done (or a less intentional version of the same) to flood
> your logs with crap.
and fsize becomes immutable as well apparently (syslog be forgotten)
here is something that doesn't require patching
create log files and change to system append-only with chflags. dir
should be, e.g., chown root:wheel, chmod go=rx
#include
#include
#include
#define sp "/usr/bin/script"
#define sf "/var/db/ghetto_act/%ju"
main()
{
char *so;
if (asprintf(&so, sf, getuid()) == -1) return 1/0;
execl(sp, sp, "-a", so, NULL);
return 1/0;
}
>
> Why is this a good idea, exactly ?
>
> Paul 'WEiRD' de Weerd
>
> --
>>[<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
o look, a brainfuck program. this is so quirky and tech oriented i
feel identified with you
> http://www.weirdnet.nl/
Re: KSH command logged to syslog
My guess, compliance to some standard
Den 16 dec 2012 11:17 skrev "Paul de Weerd" :
> On Sun, Dec 16, 2012 at 11:02:31AM +0100, David Coppa wrote:
> | > .profile can be interrupted with ctrl+c.
> |
> | >>> Because it is under controle or the user and he/she can disable
> | >>> such funcionality.
> |
> | the safer way imho is patching ksh
>
> After that, expect all your users to suddenly switch to one of the
> other shells available on your system...
>
> Or a nice syslog DoS, where people run while :; do echo ${RANDOM} >
> /dev/null; done (or a less intentional version of the same) to flood
> your logs with crap.
>
> Why is this a good idea, exactly ?
>
> Paul 'WEiRD' de Weerd
>
> --
> >[<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
> http://www.weirdnet.nl/
Re: KSH command logged to syslog
On Sun, Dec 16, 2012 at 11:02:31AM +0100, David Coppa wrote:
| > .profile can be interrupted with ctrl+c.
|
| >>> Because it is under controle or the user and he/she can disable
| >>> such funcionality.
|
| the safer way imho is patching ksh
After that, expect all your users to suddenly switch to one of the
other shells available on your system...
Or a nice syslog DoS, where people run while :; do echo ${RANDOM} >
/dev/null; done (or a less intentional version of the same) to flood
your logs with crap.
Why is this a good idea, exactly ?
Paul 'WEiRD' de Weerd
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
Re: KSH command logged to syslog
> .profile can be interrupted with ctrl+c. >>> Because it is under controle or the user and he/she can disable >>> such funcionality. the safer way imho is patching ksh
Re: Replication option for ldapd(8)
11 dec 2012 kl. 11:40 skrev Joel Carnat : > Hello, > > I want to achieve a Master / Slave replication with OpenBSD's shipped > ldapd(8). > > Are there any native features to synchronize both instances (like openldap's > syncrepl) or do I have to script a bunch of (ldapsearch/ldapadd)|scp ? There's no native replication support yet. .martin > TIA, > Jo
