Re: What tty changes - question on porting ltmdm and hcfmdm to FreeBSD 8
On Fri, 23 Apr 2010 16:27:12 -0700 Ted Mittelstaedt t...@mittelstaedt.us wrote: Setting aside the question of why do we break software that a lot of people use (these chips are in use on a lot of laptops) is there a document somewhere that explains what changes need to be made in code for this new tty setup? Or, is there a set of magic include files or a conversion shim library that will allow these kinds of programs to build without much work? Or is porting these drivers just so non-trivial that the only way is to just delve into the system manuals and delve into the driver code and try to figure out what is going on in each? If that's the case that's probably beyond my ability but I'd be happy to serve as a testbed. The guy to ask about this would be Ed Schouten (ed@). AFAICR he did the new TTY stuff. I don't know whether he reads these lists. AFAIK there is no easy way to fix this and there are no backwards compati- bilty shims or magic header files. The fundamental problem with ltmdm is that it's a KLD and has to grovel around in the guts of the kernel. That makes fixing it decidely non- trivial. -- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: How to change vnode operations ?
On Fri, 23 Apr 2010, Gleb Kurtsou wrote:
Date: Fri, 23 Apr 2010 12:22:57 +0300
From: Gleb Kurtsou gleb.kurt...@gmail.com
To: Lukáš Czerner czerner.lu...@gmail.com
Cc: freebsd-hackers@freebsd.org
Subject: Re: How to change vnode operations ?
On (23/04/2010 08:10), Lukáš Czerner wrote:
On Thu, 22 Apr 2010, Gleb Kurtsou wrote:
Date: Thu, 22 Apr 2010 22:18:49 +0300
From: Gleb Kurtsou gleb.kurt...@gmail.com
To: Lukáš Czerner czerner.lu...@gmail.com
Cc: freebsd-hackers@freebsd.org
Subject: Re: How to change vnode operations ?
On (22/04/2010 16:02), Lukáš Czerner wrote:
Hi all,
this may sound a little odd, since I have noticed that there is much
work done to not allow such a thing ($SUBJ). But may be you can help
me and point me to the right direction.
I am writing a kernel module with somewhat similar functionality
like nullfs has, BUT it has to have some features which nullfs
itself does not provide :
1. I need the new layer to completely hide underlaying layer so no
one can bypass it.
Is hypothetic 'mount -t mynullfs /a /a' good enough for you? I'm not sure
what your goals are but completely finding underlaying filesystem won't
be easy because of VFS_GET, getfh and other stuff operating with inode
numbers.
Well, it may be good enough, or not. Thats what I am trying to find
out. Obviously there are problems, as you mentioned, which will not
exist when I change the vop_vector of the vnode, but as I thought
and you mentioned it as well, this is not very clean way.
Why don't you like stacked filesystem approach? It's designed to solve
the problem you are describing if I get it right. Although creating
pefs-like filesystem altering data and names is not so easy within
existing framework.
2. Nullfs allows me to to overlay just one directory, but i want to
include another directories and/or exclude subdirectories/files.
3. Nullfs just redirects vnode operations to lower layer, I need to
catch that operation, do something (for example alter the arguments
somehow etc..), pass the operation (with possibly altered arguments)
to the lower layer, get the result and then return the result.
I'd suggest to take a look at pefs: http://github.com/glk/pefs
It's cryptographic stacked filesystem for FreeBSD. It changes file
names, hides directory entries, modifies data from lower layer
(encrypts or decrypts), supports mounting on same directory, etc.
Thats great, thanks! I will look at it.
The best way to do that (I think) is to change vnode operations of
particular vnodes to point to functions defined in that module. At
this point, I can catch any operations with the vnode and this is
the base of what i want.
So my question is. I there any clean way to chande vnode
operations ? If not, is there any not so clean way ? Anyway I will
appreciate any good idea how to do what I have described.
Imho, stacked filesystem is the only right way to do it (see null,
unionfs, pefs).
OK. Thanks for pointing me to the pefs, it is interesting and looks
like a good start. But I would appreciate more comment on the side
of the whole idea about changing vnode operations from the kernel
module. It is a little hacky, but aside this I do not see any bigger
problems, do you ?
Changing vop_vector is too hackish for me. Basically, changing vnode
operations is what stacked filesystems are about. Vnode operations are
the top of the problem, you would also have to deal with parent lookup,
namecache consistency and buffering, which is going to be complicated.
I.e. you'd have to partially reimplement part of VFS layer.
nullfs and unionfs pass vnode vobject (buffering layer) from lower
layer, adding your own vobject to vnode would complicate filesystem
significantly. Besides you won't be able to assign 2 vobjects (original
and your own) to a single vnode if you decide to change operations
vector.
This is exactly how I feel about it and I am glad that you actually
confirm that, so thank you. Now I am convinced to use stacked
filesystem.
But I have one last question, though. It may be stupid, but when I
am looking at your pefs I can not figure out how you manage to mount
directory above itself. I am staring at the code and just do not see
that. It seems to me, like the check is done before the
{pefs|nullfs}_mount is even called. Can you point me out to the
right direction ?
Thanks again!
-Lukas.___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Keyboard scancodes
Le Fri, 23 Apr 2010 11:20:50 +0200, Michael Cardell Widerkrantz m...@hack.org a écrit : I was recently given an original Happy Hacking Keyboard. As I sometimes work in the FreeBSD console, I wanted to have my usual console keymap adjusted to the new keyboard, but didn't know the scancode for the HHKB meta key (the diamond key). I couldn't find any program in base or ports that would show me the scancodes, so I ended up writing my own: http://hack.org/mc/hacks/kbdscan/ Thanks, that could be usefull when doing syscons keymap. Last time I did it, I put some printf into the keyboard driver :( Regards. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Distributed SSH attack
On 04/16/2010 05:18, krad wrote:
On 16 April 2010 09:39, David Xu davi...@freebsd.org wrote:
Jeremy Lea wrote:
Hi,
This is off topic to this list, but I dont want to subscribe to -chat
just to post there... Someone is currently running a distributed SSH
attack against one of my boxes - one attempted login for root every
minute or so for the last 48 hours. They wont get anywhere, since the
box in question has no root password, and doesn't allow root logins via
SSH anyway...
But I was wondering if there were any security researchers out there
that might be interested in the +-800 IPs I've collected from the
botnet? The resolvable hostnames mostly appear to be in Eastern Europe
and South America - I haven't spotted any that might be 'findable' to
get the botnet software.
I could switch out the machine for a honeypot in a VM or a jail, by
moving the host to a new IP, and if you can think of a way of allowing
the next login to succeed with any password, then you could try to see
what they delivered... But I don't have a lot of time to help.
Regards,
-Jeremy
Try to change SSH port to something other than default port 22,
I always did this for my machines, e.g, change them to 13579 :-)
Regards,
David Xu
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
dont allow password auth, tcp wrap it, and acl it with pf. Probably more
stuff you can do. Think onions
Not allowing password auth also means turning off PAM authentication for
logins with openssh and has the resulting effect utmp not being updated
among other things. Be sure you want to go this route.
tcpwrap it ? that is unneeded. The moment you start configuring
hosts.allow your system is going to be sending requests for ident. Its a
bad idea with all the other options that are available.
pf (GREAT IDEA!) I use the following for example on a home box to limit
the exposure to attacks.
shports=ssh
table blacklist file /etc/pf/tables/blacklist
... some other rules ...
block log quick from blacklist label Blacklisted
some more rules ...
pass in log quick proto { tcp } from any port 1024 to any port \
{ $shports } label SSH/Login:$dstport keep state (max-src-conn \
5, max-src-conn-rate 15/30 overload blacklist flush global)
pass out all label Implicit
Soon as a offender violates this they end up in the blacklist which I
run below url on every 3 hours to save to the file listed in the table
store above:
http://tinyurl.com/29y4zdh
Good luck.
--
jhell
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: What tty changes - question on porting ltmdm and hcfmdm to FreeBSD 8
In message: 20100424102255.12d78...@ernst.jennejohn.org Gary Jennejohn gljennj...@googlemail.com writes: : On Fri, 23 Apr 2010 16:27:12 -0700 : Ted Mittelstaedt t...@mittelstaedt.us wrote: : :Setting aside the question of why do we break software that a lot of : people use : (these chips are in use on a lot of laptops) is there a document : somewhere that explains : what changes need to be made in code for this new tty setup? Or, is : there a set : of magic include files or a conversion shim library that will allow : these kinds : of programs to build without much work? : :Or is porting these drivers just so non-trivial that the only way is : to just delve into : the system manuals and delve into the driver code and try to figure out : what is : going on in each? If that's the case that's probably beyond my ability : but I'd : be happy to serve as a testbed. : : : The guy to ask about this would be Ed Schouten (ed@). AFAICR he did the new : TTY stuff. I don't know whether he reads these lists. : : AFAIK there is no easy way to fix this and there are no backwards compati- : bilty shims or magic header files. : : The fundamental problem with ltmdm is that it's a KLD and has to grovel : around in the guts of the kernel. That makes fixing it decidely non- : trivial. The fundamental reason that things changed was due to the locking of the TTY layer. These things change over time, and the old APIs made it very difficult to lock without driver visible changes. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
kern+world / ports make options
Hello Hackers Current, I was wondering it if is possible, or if it can be done so a separate set of CC, CXX, etc can be specified for building the world and kernel independently of a ports build? Right now, I use the base GCC to compile the world and kernel, and GCC44 for most of the other ports (when it complies cleanly). But I have to keep editing the /etc/make.conf file to switch between the two. It may already be implemented, but it would be nice if there was something defined while the kernel and/or world is being built to that a nested block of ifdefs can select which env variables to be set. Peg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kern+world / ports make options
On Sat, Apr 24, 2010 at 5:42 PM, Pegasus Mc Cleaft k...@mthelicon.com wrote: Hello Hackers Current, I was wondering it if is possible, or if it can be done so a separate set of CC, CXX, etc can be specified for building the world and kernel independently of a ports build? Right now, I use the base GCC to compile the world and kernel, and GCC44 for most of the other ports (when it complies cleanly). But I have to keep editing the /etc/make.conf file to switch between the two. It may already be implemented, but it would be nice if there was something defined while the kernel and/or world is being built to that a nested block of ifdefs can select which env variables to be set. Peg man src.conf Cheers Tom ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: What tty changes - question on porting ltmdm and hcfmdm to FreeBSD 8
On 4/24/2010 8:29 AM, M. Warner Losh wrote: In message:20100424102255.12d78...@ernst.jennejohn.org Gary Jennejohngljennj...@googlemail.com writes: : On Fri, 23 Apr 2010 16:27:12 -0700 : Ted Mittelstaedtt...@mittelstaedt.us wrote: : :Setting aside the question of why do we break software that a lot of : people use : (these chips are in use on a lot of laptops) is there a document : somewhere that explains : what changes need to be made in code for this new tty setup? Or, is : there a set : of magic include files or a conversion shim library that will allow : these kinds : of programs to build without much work? : :Or is porting these drivers just so non-trivial that the only way is : to just delve into : the system manuals and delve into the driver code and try to figure out : what is : going on in each? If that's the case that's probably beyond my ability : but I'd : be happy to serve as a testbed. : : : The guy to ask about this would be Ed Schouten (ed@). AFAICR he did the new : TTY stuff. I don't know whether he reads these lists. : : AFAIK there is no easy way to fix this and there are no backwards compati- : bilty shims or magic header files. : : The fundamental problem with ltmdm is that it's a KLD and has to grovel : around in the guts of the kernel. That makes fixing it decidely non- : trivial. The fundamental reason that things changed was due to the locking of the TTY layer. These things change over time, and the old APIs made it very difficult to lock without driver visible changes. Warner I mailed Ed and his response is to look at the changelog of sys/dev/uart/uart_tty.c for an idea of how to rewrite the driver, so I will take a look there. The ltmdm driver was updated in 2008 for an early version of FreeBSD 8, before the TTY layer changes went in, so that's where I'll start. Ted ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kern+world / ports make options
On 04/24/10 09:42, Pegasus Mc Cleaft wrote: Hello Hackers Current, Please don't crosspost. If you're not what list to post to, the algorithm is: If the question is about a port, or the ports in general, use freebsd-ports@, otherwise use freebsd-questi...@. This post should have gone to -ports. I was wondering it if is possible, or if it can be done so a separate set of CC, CXX, etc can be specified for building the world and kernel independently of a ports build? Since you didn't say what version of FreeBSD you're using, try doing 'man src.conf' to see if you can separate your base-related variables into that file. Either way, you should also check out ports-mgmt/portconf to handle ports-only stuff. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Distributed SSH attack
On 24 April 2010 14:46, jhell jh...@dataix.net wrote: On 04/16/2010 05:18, krad wrote: On 16 April 2010 09:39, David Xu davi...@freebsd.org wrote: Jeremy Lea wrote: Hi, This is off topic to this list, but I dont want to subscribe to -chat just to post there... Someone is currently running a distributed SSH attack against one of my boxes - one attempted login for root every minute or so for the last 48 hours. They wont get anywhere, since the box in question has no root password, and doesn't allow root logins via SSH anyway... But I was wondering if there were any security researchers out there that might be interested in the +-800 IPs I've collected from the botnet? The resolvable hostnames mostly appear to be in Eastern Europe and South America - I haven't spotted any that might be 'findable' to get the botnet software. I could switch out the machine for a honeypot in a VM or a jail, by moving the host to a new IP, and if you can think of a way of allowing the next login to succeed with any password, then you could try to see what they delivered... But I don't have a lot of time to help. Regards, -Jeremy Try to change SSH port to something other than default port 22, I always did this for my machines, e.g, change them to 13579 :-) Regards, David Xu ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org dont allow password auth, tcp wrap it, and acl it with pf. Probably more stuff you can do. Think onions Not allowing password auth also means turning off PAM authentication for logins with openssh and has the resulting effect utmp not being updated among other things. Be sure you want to go this route. tcpwrap it ? that is unneeded. The moment you start configuring hosts.allow your system is going to be sending requests for ident. Its a bad idea with all the other options that are available. Not by default it doesnt. Even then ident wont happen to random hosts only ones you trust as you will be protected via pf/ipfw/iptables, its just their as a safety net. I did mention onions I thought. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
BIO_FLUSH and ips(4)
Hello. The ServeRAID driver, or ips(4), seems to distinguish read or write requests with a macro called ips_read_request(), which is defined as #define ips_read_request(iobuf) ((iobuf)-bio_cmd == BIO_READ) in its strategy routine and a few other places. So when the request is BIO_FLUSH, the ips driver issues a write command (IPS_WRITE_CMD) with length == 0, right? My question is, do ServeRAID controllers treat 0-byte write command as a sync-to-disk request, or is there any command for that purpose? There's a command called IPS_CACHE_FLUSH_CMD defined in ipsreg.h, but it's not used anywhere in the normal code path. Best regards, YONETANI Tomokazu. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: BIO_FLUSH and ips(4)
Hi, On Sat, Apr 24, 2010 at 8:20 PM, YONETANI Tomokazu qhwt+f...@les.ath.cx wrote: Hello. The ServeRAID driver, or ips(4), seems to distinguish read or write requests with a macro called ips_read_request(), which is defined as #define ips_read_request(iobuf) ((iobuf)-bio_cmd == BIO_READ) in its strategy routine and a few other places. So when the request is BIO_FLUSH, the ips driver issues a write command (IPS_WRITE_CMD) with length == 0, right? My question is, do ServeRAID controllers treat 0-byte write command as a sync-to-disk request, or is there any command for that purpose? There's a command called IPS_CACHE_FLUSH_CMD defined in ipsreg.h, but it's not used anywhere in the normal code path. It seems Linux driver is using it (on shutdown/reset) but I'm not sure if this would have some side effect, etc.? Cheers, -- Xin LI delp...@delphij.net http://www.delphij.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
